Date: Sat, 2 Nov 2024 15:53:02 +0100
Thank you, Jens Maurer, for considering my proposal as sent to
wg21bot_at_gmx.net.
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.
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]>
ha scritto:
>
> I've made CWG2948 for this:
>
> 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]> instead of std-proposals ?
> > - May I directly write now to wg21bot_at_[hidden] <mailto:wg21bot_at_[hidden]> as
> indicated on 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]>> 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]>>
> wrote:
> >
> > For working draft on 30th-Oct-2024 (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]>
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
> >
> >
> >
> > --
> > /Brian Bi/
> >
> >
>
>
wg21bot_at_gmx.net.
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.
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]>
ha scritto:
>
> I've made CWG2948 for this:
>
> 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]> instead of std-proposals ?
> > - May I directly write now to wg21bot_at_[hidden] <mailto:wg21bot_at_[hidden]> as
> indicated on 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]>> 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]>>
> wrote:
> >
> > For working draft on 30th-Oct-2024 (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]>
> > 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 14:53:15