Let's design Cpp2's _requires-expression_ as a pit of success!

[JohelEGP]

Let's design Cpp2's requires-expression as a pit of success!

As it turns out, with Cpp1's requires-expression, slight changes in a requirement's syntax can still result in a valid requirement.
This results in seemingly working concept declarations that actually have unintended effects.
For examples of pitfalls, I suggest you (re)read the article https://quuxplusone.github.io/blog/2021/06/09/another-concepts-chest-mimic/ and (re)watch the linked CppCon talk.

With Cpp2, we have the opportunity to design a requires-expression for Cpp2 that is a pitfall of success.

Please, have one top-level comment per (re)design.
Feel free to have top-level comments about other concerns.

A few comments

Grammars

The sky is the limit; the grammar is free real state (as Herb's willing to hand it out).
Do not think that Cpp2's requires-expression has to be a single top-level grammar.
For example, each requirement could be usable on its own, without being within a requires-expression
(so it could be an alternative of grammars, rather than the requirement-body being a sequence of requirements).

Integration

Consider the greater picture of Cpp2; there might be tradeoffs to be had.

For example, in an is-as-expression, where the rhs argument can be a type or expression,
you can disambiguate an expression from a type by adding parentheses around it
(Herb has stated his intention to do the same for template arguments at #531 (comment)).

If we were to translate Cpp1's requirements as-is, we could use the same formulation.
For example, instead of translating Cpp1 requirements

𝘌;
typename 𝘛;

to Cpp2's terms

𝘌;
type 𝘛;

they could be translated to

(𝘌);
𝘛;

Pitfalls

Squint at what the sources of the pitfalls of Cpp1's requires-expression might be.
Besides slight changes in the syntax resulting in another valid meaning, there are also meaningless combinations.

Let's consider the first source of pitfalls, slight changes in syntax.
If we were to translate Cpp1's compound-requirement as-is, we might end up with Cpp1

{ x } -> std::integral;

being the equivalent of Cpp2's

{ x } is std::integral;

Unfortunately, this still runs into the pitfall that a user might instead write:

x is std::integral;

That is a simple-requirement, if we similarly translated that from Cpp1.
It changes the meaning; currently, an is operation always valid (or bugged) (which I argue against with #492).

Herb has also stated his intention to support terse concept syntax like <T: type is std::regular> at #575 (comment)
(I'm supposing we will be able to omit type, and similarly declare NTTPs like <V: _ is std::regular>).
So this also ties back to integration.

The other source of pitfalls is meaningless combinations.
Because a requires-expression can test arbitrary expression, it can also test requires-expressions.
It's a meaningless combination because the SFINAE-level validity of all constructs is already being checked within a requires-expression.
So adding a nested requires doesn't add value, and not rejecting that is a source of pitfalls.
This source is enhanced by the fact that a nested-requirement starts with requires in Cpp1.

[AbhinavK00]

Because a requires-expression can test arbitrary expression, it can also test requires-expressions.
It's a meaningless combination because the SFINAE-level validity of all constructs is already being checked within a requires-expression.
So adding a nested requires doesn't add value, and not rejecting that is a source of pitfalls.

So if I understand correctly, you are saying that a requires expression should not be inside another requires expression, right? Because, requires clauses inside requires expressions are useful. Also, I think cpp20 already disallows that.

Also, maybe we could have different keywords for requires expressions and requires clauses because they are confusing currently.

[JohelEGP]

Also, I think cpp20 already disallows that.

Definitely not, because it's valid and it's a pitfall.
This is what I'm talking about, from the article:

template<class T>
concept HasAButNotB = requires (T t) {
    t.a();
    !requires { t.b(); };
};

But maybe I'm wrong about banning requires within requires.
How else can you require that T doesn't have a .b()?

[JohelEGP]

I got an idea.

We still want to prohibit nested requires expressions.
What we can do is,
in addition of nested-requirement,
we could add its negation by adding an optional ! at the start of a nested-requirement.

We use this pattern a lot in mp-units' unit tests to test that our generic functions don't work for unexpected inputs.
For example, see https://github.com/mpusz/mp-units/blob/caab43cd256e4c617f57b896afb5780d1353f119/test/unit_test/static/quantity_test.cpp#L51-L59.
So by

• prohibiting requires !requires { 𝘴𝘵𝘶𝘧𝘧; },
• permitting !requires { 𝘴𝘵𝘶𝘧𝘧; }, and
• prohibiting nested requires-expressions,

we remove the pitfall and keep the valid use cases.

[AbhinavK00]

One concern

!requires { 𝘴𝘵𝘶𝘧𝘧; }

is always be satisfied in cpp1 so we should prohibit that one. Or maybe I misunderstood and you actually mean allowing it in cpp2 which would lower to cpp1's

requires !requires { 𝘴𝘵𝘶𝘧𝘧; }

Right?

[JohelEGP]

That's right (the latter).

[AbhinavK00]

I'll give some code examples
The following is your example which is valid but wrong

template<class T>
concept HasAButNotB = requires (T t) {
    t.a();
    !requires { t.b(); };
};

The following example shows why I think "it" is banned in cpp20, this will error out

template<class T>
concept HasAButNotB = requires (T t) {
    t.a();
    requires { t.b(); };
};

The following is the correct way to express our requirement

template<class T>
concept HasAButNotB = requires (T t) {
    t.a();
    requires !requires { t.b(); };
};

Also, I think you're right about banning requires inside requires upto some extent. requires expressions should not be allowed (probably aren't in cpp20 but have to check that) but requires clauses are still useful as demonstrated by above example.

This also supports my point about having high distinction between requires clauses and requires expressions maybe even upto having different keywords for them. And cppfront definitely needs to simplify this design space largely so users don't fall into pitfalls like above.

[JohelEGP]

What you call a requires clause in the example is actually a third grammar that begins with requires.
It's a nested-requirement (the other two being requires-clause and requires-expression).

This also supports my point about having high distinction between requires clauses and requires expressions maybe even upto having different keywords for them. And cppfront definitely needs to simplify this design space largely so users don't fall into pitfalls like above.

I'm really glad you voiced out this concern.
It's been a known issue forever.
But Cpp1 just wouldn't dare to take up more keywords,
and you could even say the contextual overloading of requires makes sense.

I considered this, but can't come up with any solution.
And if I ever came across a better suggestion that would fit Cpp2, I certainly don't remember.
Maybe you can find a suggestion out there whose frame really fits Cpp2.

[AbhinavK00]

Isn't that same as a requires clause which is nested though? it works the same, takes a boolean and makes acts a toggle on/off switch in the encompassing requires expression.
Sry if it's a stupid question, I just woke up

[JohelEGP]

The grammar of a requires-clause is more constrained.
Which I believe would be a semantic constraint in Cpp2,
which just uses the same grammar of nested-requirement, namely logical-or-expression.

[JohelEGP]

Here's the CppCon talk's pitfalls for requires-expressions.

• https://youtu.be/CXn02MPkn8Y?t=2337:
  simple-requirement.
  Cpp1: -t -> T vs. { -t } -> T.
  Cpp2: x is T vs. { x } is T (my literal translation from the Cpp1 grammar).
• https://youtu.be/CXn02MPkn8Y?t=2418:
  boolean simple-requirement, e.g. sizeof(T) == 4;.
  Maybe lower a Cpp2 simple-requirement 𝘌;
  to a Cpp1 compound-requirement { 𝘌 } -> cpp2::not_boolean-testable_or_static_assert;.
  The error message should point out that maybe it was meant to be a constraint.
  And that if it isn't the case, to convert it the compound-requirement { 𝘌 } is bool; or to discard it (_ = 𝘌;).
• https://youtu.be/CXn02MPkn8Y?t=2455:
  Cpp1: noexcept ( ++t );, requires noexcept( ++t );, { ++t } noexcept;.
  Cpp2: N/A (ATM?).

[AbhinavK00]

I mean for { 𝘌 } is 𝘛; to lower to { 𝘌 } -> 𝘛;.

Ok, sorry for the confusion. I get it now but E is T shouldn't lower E -> T which you already implied.

[JohelEGP]

I didn't imply that.
I did mention that the problem of missing the braces in Cpp1 applies to Cpp2.
So Cpp1 𝘌 -> 𝘛 could be a typo for { 𝘌 } -> 𝘛,
and Cpp2 𝘌 is 𝘛 could be a typo for { 𝘌 } is 𝘛.

[AbhinavK00]

Yes and the following semantic rule proposed by you should take care of this

Semantic rule: Not on compound-requirement, but on a expression requirement.
An expression does not satisfy boolean-testable (i.e., if it does, the implementation shall emit a diagnostic).
Intent: To prevent #588 (comment) bullets 1 and 2.
Those pitfalls become compile-time errors, and the user should do one of these:

Move 𝘌; outside the requires-expression if that's what they meant
(i.e., as a term of a requires-clause when 𝘌 is a constant expression that satisfies boolean-testable).
Discard it with _ = 𝘌; if it's actually expressed correctly and 𝘌 can satisfy boolean-testable.
Transform it to { 𝘌 } is std::convertible_to; or something along those lines if that's what they meant.

And therefore E is T should be invalid and the correct way of writing that would be { E is T } is bool.

[JohelEGP]

Yes, that's part of my proposed design: #588 (comment).

[JohelEGP]

The second bullet, also at "What's New in Compiler Explorer? - Matt Godbolt - C++ on Sea 2023".

[JohelEGP]

Here's my design, based on "no gratuitous difference from Cpp1".
It's basically a compilation of my other comments and a restriction on inspect.
If my statements about them are correct, they could even be proposals for Cpp1.

// requires-expression:
//     'requires' parameter-declaration-list? requirement-body
//
// requirement:
//     type-id ';'          // Cpp1 type-requirement
//     expression ';'       // Cpp1 simple-requirement
//     compound-requirement
//     nested-requirement

Semantic rule: A (possibly negated) nested requires-expression may only appear as a term of a nested-requirement.
Intent: To prevent the subject of https://quuxplusone.github.io/blog/2021/06/09/another-concepts-chest-mimic/.

// compound-requirement:
//     { expression } 'throws'? is-type-constraint? ';'

Maybe not really is-type-constraint, but whatever grammar Herb adds or uses for <T: type is std::regular> (see #575 (comment)).
Most compound-requirements will have to be throws, just like how most function types would have to be throws with my #526.

Semantic rule: Not on compound-requirement, but on a expression requirement.
An expression does not satisfy boolean-testable (i.e., if it does, the implementation shall emit a diagnostic).
Intent: To prevent #588 (comment) bullets 1 and 2.
Those pitfalls become compile-time errors, and the user should do one of these:

• Move 𝘌; outside the requires-expression if that's what they meant
  (i.e., as a term of a requires-clause when 𝘌 is a constant expression that satisfies boolean-testable).
• Discard it with _ = 𝘌; if it's actually expressed correctly and 𝘌 can satisfy boolean-testable.
• Transform it to { 𝘌 } is std::convertible_to<bool>; or something along those lines if that's what they meant.

// nested-requirement:
//     '!'? 'requires' logical-or-expression ';'

When ! is present, results in the negated value of the same nested-requirement without !.
Intent: To help prevent the subject of https://quuxplusone.github.io/blog/2021/06/09/another-concepts-chest-mimic/
by making the formulation of a "has no" requirement a first-class construct.

If proposing these to Cpp1, requires !requires { 𝘴𝘵𝘶𝘧𝘧; } can remain valid, but possibly deprecated.

[JohelEGP]

That might be possible.
We can even do it with throws.

{ 𝘌 } throws, is 𝘊;
𝘌 throws -> 𝘊; // No `{}` anymore.
𝘌 -> 𝘊; // Non potentially-throwing 𝘌.

Unfortunately, this isn't only inconsistent with the planned introduction of is 𝘊 by #575 (comment),
but it's also inconsistent with Cpp1.
I'll stick with being more consistent with Cpp1 and consistent with Cpp2.

[JohelEGP]

Why did I have to do this change: JohelEGP@17caed1#diff-e7cad51d49cc330296fa31a67e79b5d1497bd068bafaabd30bca2951f0f6ab19L4-R5?
Somehow, it was making the tests I expected to pass, not pass.
It turns out I was using a concept, which is "always" valid.
So the negative requirement was to never pass.
What I wanted to test was indirection, or std::iter_reference_t<T>.
Here, the semantic requirement of non-convertibility to boolean would have helped me.
EDIT: Actually, that currently parses like a type requirement. So my result above raced with moving negative-requirement into its own grammar with commit 17caed1.

[JohelEGP]

Semantic rule: A (possibly negated) nested requires-expression may only appear as a term of a nested-requirement.
Intent: To prevent the subject of https://quuxplusone.github.io/blog/2021/06/09/another-concepts-chest-mimic/.

I think this is completely taken care of by

• requiring an expression requirement to not be convertible to bool, and
• adding negative requirement as a first-class construct.

[JohelEGP]

Most compound-requirements will have to be throws, just like how most function types would have to be throws with my #526.

All would-be simple-requirements in Cpp1 have to be Cpp2 compound-requirements with throws specified.

[JohelEGP]

I'm implementing this at https://github.com/JohelEGP/cppfront/tree/requires-expression.

Opened #596 for this.