got your answer n. 11490 about avoiding to extend the example in
[temp.arg.template]-2.

Two other topics.

*) Despite it is ok to me not considering the 'note' that I proposed in the
original email, I still see valuable to refer
[temp.spec.partial.ordering] from the extended text in
[temp.spec.partial.general]-1, just as it refers [temp.spec.partial.match].

*) how it works about eventually applying the change also for previous
standard versions ? Is it really possible ?

Thank you.




Il giorno sab 2 nov 2024 alle ore 17:41 Jens Maurer <jens.maurer_at_[hidden]>
ha scritto:

>
>
> On 02/11/2024 15.53, mauro russo wrote:
> > Thank you, Jens Maurer, for considering my proposal as sent to
> wg21bot_at_[hidden] <mailto:wg21bot_at_[hidden]>.
> >
> > I see you agreed on the fix (by rewording a bit, and dropping the
> 'note'), as well as on avoiding to repeat the same concept twice in
> [temp.arg.template]-2 and [temp.spec.partial.general]-1.
> > Thank you for that.
> >
> > I hope you may still consider, in addition, the extension I proposed for
> the code example in [temp.arg.template]-2.
>
> No. This is about template template-parameters, and we already have an
> example
> highlighting the mechanics of partial specialization for that. I don't
> think the
> IFNDR situation is so important that we need to add an example in a
> section that
> doesn't have the corresponding normative rule (anymore).
>
> Jens
>
>
> > Let me paste here, where I used <ins></ins> tags.
> >
> > [Example 1:
> > template<class T> class A { // primary template
> > int x;
> > };
> > template<class T> class A<T*> { // partial specialization
> > long x;
> > };
> >
> > <ins>
> > template<int N> class B{}; // primary template
> >
> > template<int N> requires (N < 5)
> > class B<N>{}; // first partial specialization
> > </ins>
> >
> > template<template<class U> class V
> > <ins>
> > , template<int K> class W
> > </ins>
> >> class C {
> > V<int> y;
> > V<int*> z;
> > <ins>
> > W<4> n;
> > </ins>
> >
> > };
> > C<A
> > <ins>
> > , B
> > </ins>
> >> c; // V<int> within C<A<ins>,B</ins>> uses the primary
> template, so c.y.x has type int
> > // V<int*> within C<A<ins>,B</ins>> uses the partial
> specialization, so c.z.x has type long
> > <ins>
> > // W<4> within C<A,B> uses the first partial
> specialization
> > </ins>
> >
> > <ins>
> > template<int N> requires (N < 5)
> > class B<N>{}; // late ambiguous partial specialization for C<A,B>.W<4>
> > </ins>
> >
> > — end example]
> >
> >
> > Mauro.
> >
> > Il giorno sab 2 nov 2024 alle ore 15:04 Jens Maurer <jens.maurer_at_[hidden]
> <mailto:jens.maurer_at_[hidden]>> ha scritto:
> >
> >
> > I've made CWG2948 for this:
> >
> > https://cplusplus.github.io/CWG/issues/2948.html <
> https://cplusplus.github.io/CWG/issues/2948.html>
> >
> > Jens
> >
> >
> > On 02/11/2024 08.36, mauro russo via Std-Proposals wrote:
> > > | I think this should be an ill-formed, no diagnostic required
> (IFNDR) situation, just like how [temp.spec.partial.general]/1 specifies
> IFNDR. It's nice that GCC diagnoses it, but we don't want to require
> compilers, upon seeing new partial specializations, to have to go back and
> check that they don't "ambiguate" prior template instantiations.
> > >
> > > | It seems the standard wording should be amended to include this
> case. This can probably be done via core issue.
> > >
> > >
> > > I totally agree. Please, suggest a way to go on.
> > >
> > > - Should I have sent an email to std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]> <mailto:
> std-discussion_at_[hidden] <mailto:std-discussion_at_[hidden]>>
> instead of std-proposals ?
> > > - May I directly write now to wg21bot_at_[hidden] <mailto:
> wg21bot_at_[hidden]> <mailto:wg21bot_at_[hidden] <mailto:wg21bot_at_[hidden]>> as
> indicated on https://isocpp.org/std.submit-issue <
> https://isocpp.org/std.submit-issue> <https://isocpp.org/std.submit-issue
> <https://isocpp.org/std.submit-issue>> ?
> > >
> > > Mauro.
> > >
> > > Il giorno sab 2 nov 2024 alle ore 04:07 Brian Bi <
> bbi5291_at_[hidden] <mailto:bbi5291_at_[hidden]> <mailto:bbi5291_at_[hidden]
> <mailto:bbi5291_at_[hidden]>>> ha scritto:
> > >
> > > On Thu, Oct 31, 2024 at 12:12 PM mauro russo via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>
> <mailto:std-proposals_at_[hidden] <mailto:
> std-proposals_at_[hidden]>>> wrote:
> > >
> > > For working draft on 30th-Oct-2024 (
> https://eel.is/c++draft/ <https://eel.is/c++draft/> <
> https://eel.is/c++draft/ <https://eel.is/c++draft/>>)
> > >
> > > In both [temp.arg.template]-2 and
> [temp.spec.partial.general]-1, the standard requires that in each
> translation unit the partial specializations are reachable in all points of
> implicit or explicit instantiations where they would have been selected if
> they had been reachable.
> > > That is, it is not allowed to declare specializations
> after instantiations where the former would have been selected.
> > >
> > > However, I guess the text should consider a more general
> case when the early declaration would lead to an ambiguity, that is, the
> postponed declaration would be in the set of best selectable
> specializations, not necessarily the unique winner. Technically, speaking,
> to refer that no more specialized specializations should be before the
> instantiation (really, it does not matter before or after as, in case of
> after, the error would exist for the more specialized one)].
> > >
> > > e.g.
> > >
> > > template<int N>
> > > class C{};
> > >
> > > template<int N>
> > > requires (N < 6)
> > > class C<N>{};
> > >
> > > C<4> x; // would have matched both constrained
> specializations, that are not partially ordered when compared each other
> > >
> > > template<int N>
> > > requires (N < 5)
> > > class C<N>{};
> > >
> > > Indeed, gcc 14.2 raises a compilation error when second
> specialization is declared ('declaration of 'class CL<N>' ambiguates
> earlier template instantiation for 'class CL<4>'').
> > > Both mvsc 19.4 and clang 19.1 do not.
> > > However, the standard does not require diagnostic.
> > >
> > >
> > > I think this should be an ill-formed, no diagnostic required
> (IFNDR) situation, just like how [temp.spec.partial.general]/1 specifies
> IFNDR. It's nice that GCC diagnoses it, but we don't want to require
> compilers, upon seeing new partial specializations, to have to go back and
> check that they don't "ambiguate" prior template instantiations.
> > >
> > > It seems the standard wording should be amended to include
> this case. This can probably be done via core issue.
> > >
> > >
> > >
> > > Mauro.
> > > --
> > > Std-Proposals mailing list
> > > Std-Proposals_at_[hidden] <mailto:
> Std-Proposals_at_[hidden]> <mailto:Std-Proposals_at_[hidden]
> <mailto:Std-Proposals_at_[hidden]>>
> > >
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals> <
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>>
> > >
> > >
> > >
> > > --
> > > /Brian Bi/
> > >
> > >
> >
>
>