references apply only to class types, and its a valid question because the
template argument itself is a const-lvalue if it is a class type. There
might actually be a difference as, if I remember correctly, and if I don’t
I’m sure everyone here will get on my case, the parameter just needs to be
LiteralType and have Strong Structural Ordering, it does not need to have a
copy or move constructor which can be evaluated in a constant expression
(or even have a non-deleted copy/move constructor). If the templates are
copied when they are lvalues, how would this proposal deal with that?
I’m also still questioning whether this proposal is necessary as an opt-in
feature, as we can effectively do this already, with a combination of using
declarations, and constexpr field declarations.

On Fri, Nov 1, 2019 at 5:17 PM Dmitry via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> So, I have incorporated (all) your feedback in the proposal:
>
> - now the feature is opt-in
> - private/protected/public keywords are used: template<public typename
> A, protected int B>
> - New compiler errors are discussed: when there is a propagated
> template parameter and user-defined one with the same name.
>
> Here is a link
> <https://docs.google.com/document/d/1dx9zuklyI1l4wU2buGaDuZGik1nAdd1YAJZ4mjwS9FU/edit#heading=h.uuouxp4cefr2> to
> the proposal (leading directly to the new opt-in approach).
>
> And also there are my thoughts on the question about the upcoming class
> types in non-type template parameters
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r0.pdf>:
> "Namely, do we want to have references (static constexpr int &B = _B; in
> the example above), or values (static constexpr int B = _B;)?
> No matter how smart structures it will be possible to use as template
> arguments, (after instantiation) they are just smartly-mangled
> (16IntegralConstantIPFiRiEXadL_Z3fooIiEiRT_EEE) old plain C structs, and
> they are entirely handled in compile-time. From this point of view, there
> is little point in using references. Perhaps, a safer approach would be to
> understand how compile-time calculations implemented in the modern
> compilers, in particular whether "compile-time reference" makes sense or
> not."
>
> --
> Dmitry
> *Sent from gmail*
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>