>> 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. ...

ok, got it. Sorry for the unfair example and thank you
for the explanation about this case.

However, the rationale behind my thought is still the same.
Therefore, let me use an alywas-invalid-expression
inspired from one present in the standard itself (at
p5 of [expr.prim.req.general]) :

template<typename T>
requires (!static_cast<void>(T{}))
int func(){return 0;};

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

int a = func<int>();

int main(){}

In case this further example is again not fair
for any reason, please, let me know whether
in your opinion it is impossible to have an invalid
expression or type which is always invalid, in the
expression of an atomic constraint.
This would be the only way, in my current opinion,
that makes [temp.res.general] p(6.4) fair.
Should I just use something fixed without using
template parameters to get one fair ? e.g. (float{}::value > 0)

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

Great, we are on the same page here.

Weel, again, func<int> leads to a satisfation check
for the first overload, too, right ?

Therefore, provided that the example above is fair,
or that an always-invalid-expression is possible,
then [temp.res.general] p(6.4) will not be applicable,
and so no diagnose will ever be provided by the compiler.
Again, I wonder this was the intended behaviour
for constraint-expressions, differently from requires-expressions,
as for the latter the standard requires IFNDR.

Thanks for the answers.