Thank you for the feedback.

The main question to answer is why do we need to hide / restrict access to
template parameters from outside at all?
Here is a toy example <https://godbolt.org/z/tE3Hh_> of what I meant when I
said that it had been possible for external code to deduce any template
parameters (type as well as non-type ones) of any template instantiation.

So, if you think, by trying to "hide" / make template arguments private /
not-visible from outside, you are suggesting to break this (already
existing) behaviour in C++.

To put it another way, the proposal does not change anything fundamentally
in this regard, instead, perhaps, it makes the trick from the toy example
<https://godbolt.org/z/tE3Hh_> less obscure and verbose.

On Thu, 31 Oct 2019 at 00:54, Miguel Ojeda via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, Oct 31, 2019 at 1:09 AM Sebastian Büttner via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > I don't think that the meaning is consistent here. Declaring something
> private isn't the same as not declaring it at all.
> >
> > Also: how is declaring a template parameter private/public affecting
> inheritance? Is the behavior consistent with class member access control?
> Is a private declared template parameter of class B not accessible in a
> derived class D? Can I declare a template parameter protected then?
> >
> > template<public class first_param, private class second_param>
>
> No need for double keyword:
>
> template <public A, protected B, private C, class D>
>
> where A/B/C are declared and D is not declared at all, as usual.
>
> For NTTPs, not sure if the grammar is ambiguous or not, though; but it
> would look clean too, e.g.:
>
> template <public size_t max_size>
>
> If there is ambiguity, there is always the classic way as fallback.
>
> Cheers,
> Miguel
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
Dmitry
*Sent from gmail*