Date: Sat, 2 Nov 2024 17:41:04 +0100
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/
> >
> >
>
> 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/
> >
> >
>
Received on 2024-11-02 16:41:11