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@lists.isocpp.org> 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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals