On Thu, Oct 31, 2024 at 12:12 PM mauro russo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> For working draft on 30th-Oct-2024 (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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*