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