We could also use export for this purpose. However there is already a
method of opting-in to this.
This also poses a question of what to do with non-type template parameters
that have class types, as is being introduced in C++20.
Would the declaration be constexpr decltype(auto) Name{Name}; (so it would
be a reference) or constexpr auto Name{Name}; (so it would be a value, and
copy the parameter)?

On Wed, Oct 30, 2019 at 7:56 PM Jake Arkinstall via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> There are keywords with a consistent meaning: public and private. I'd
> prefer those.
>
>
> On Wed, 30 Oct 2019, 23:43 Sebastian Büttner via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> I very much dislike reusing existing keywords with established meaning
>> for an entirely different purpose.
>> Even though i suspect that this is just a strawmen syntax i don't think
>> on the other hand that the suggestion is important enough to justify a
>> new keyword.
>>
>> Sebastian
>>
>> On 30.10.19 23:48, Bjorn Reese via Std-Proposals wrote:
>> > On 10/30/19 10:49 PM, Ville Voutilainen via Std-Proposals wrote:
>> >
>> >> If I then _don't_ want to expose such a template parameter name, what
>> >> do I do?
>> >
>> > The proposal could make it opt-in instead of opt-out. That would not
>> > expose existing template parameters without the consent of the
>> > template author. For example:
>> >
>> > template <explicit class value_type,
>> > explicit class allocator_type>
>> > struct vector {
>> > };
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>