On 25/02/2025 23.51, mauro russo wrote:
> Consider the following example:
>
> template<typename T>
> requires (T < -1)
> int func(){return 0;};

This doesn't satisfy the grammar of a requires-clause,
because (T < -1) is supposed to be, but is not actually,
a primary-expression. That's different from

template<class T>
requires (T::value < -1)
int func();

where we successfully parse T::value as an id-expression
(not a type).

> template<typename T>
> requires (T{} > -1)
> int func(){return 0;};
>
> int a = func<int>();

I would expect we'd do overload resolution here,
and check constraint satisfaction for both "func"
things.

> int main(){}
>
> We have two overloads for func(), the first of them
> using an always-non-satisfied constraint due to
> invalid expression (T < -1).
> Does the (implicit) instantiation of func<int>
> determine a satifaction check for the first overload ?
>
> If yes then, based on [temp.res.general] p(6.4),
> compilers should not diagnose, but on
> godbolt (https://godbolt.org/z/cqb511Wa9 <https://godbolt.org/z/cqb511Wa9>) I do
> see that gcc and clang diagnose it, whereas
> MVSC does not. This seems a case of IFNDR.

We should not require parsing and/or representation of
non-expressions such as "(T < -1)", I think.

Jens



> So, I still wonder about the apparently
> relaxed intended behaviour
> for constraint-expressions, compared to
> requires-expressions. And I do see that
> the comparison between some of major
> compilers seem showing an IFNDR case
> regardless of satisfation checks in place.
>
>
> Finally, let me notify that my last original point
> about templated vs non-template entity
> does not make sense for constraint-expressions,
> since they only appear in template declarations.