+1 on that. Opt in is the best strategy when something might mean a
once-irrelevant change could become an API break. Private by default seems
the best way forward.

Im also waiting to see what everyone thinks about the external parameter
pack expansion (I.e. In terms of viability). That's what really excites me
about this - indirection through a utility function to extract and handle
parameters is both grotesque (IMO) and commonplace.

On Thu, 31 Oct 2019, 15:10 Tae Lim Kook via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Agreed that class template parameters should be private by default, and
> having them available externally should be opt-in. There's a lot of code in
> the wild that assumes that template parameter names can be changed without
> API breakage. I like the idea of reusing access control modifiers (public,
> protected, private) for this purpose.
>
> -- T.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, October 31, 2019 8:15 AM, Dmitry via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>
>> Decomposing the type to know the template parameters is not the same as
>> making these parameters part of the class' public interface.
>>
>
>
> Right, not exactly the same.
>
> There are
>> cases when template parameters are used for auxiliary purposes, e.g. for
>> SFINAE or tagging and specialization. These parameters should not be
>> exposed.
>>
>
> It looks like this statement is the most important thing. And I am
> struggling to understand why it is so. Can you please elaborate on this
> more? Why do you think it is a bad idea? (I hope you read my proposal and
> know that if there is already a user-defined type with the same name, they
> won't be declared).
>
>
>
>> I'm strongly opposed to making the proposed behavior the default. IMO,
>> if implemented, it must be opt-in.
>>
>> Another thing to consider: unnamed template parameters.
>>
>
>
> Good point, but the answer naturally follows if you imagine what you can
> do with this unnamed parameters inside class - you can't declare
> using/typedef, ditto here, the answer to your question - there will be no
> implicitly generated typedefs.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>