feat: recognize requires expressions

[JohelEGP]

This PR adds support for requires-expressions (first based on #588 (comment)).

This is the syntax, based on Cpp1's:

Cpp2	Cpp1
number: <T> concept = requires(c: T) {	template<typename T> concept number = requires(T const& c) {
number_difference_t<T>;	typename number_difference_t<T>;
_ = T();	T();
{ c - c } !throws;	{ c - c } noexcept;
{ c + c } is std::common_with<T>;	{ c + c } -> std::common_with<T>;
requires std::common_with<number_difference_t<T>, T>;	requires std::common_with<number_difference_t<T>,T>;
!requires std::iter_reference_t<T>;	requires !requires { typename std::iter_reference_t<T>; };
};	};

The feature, as added by this PR, prevents or completely avoids known Cpp1 pitfalls.
By requiring that expression requirements are discarded, it should help to prevent the list of pitfalls at #588 (comment).
It also adds negative requirements as a first-class feature to create a pit of success for https://quuxplusone.github.io/blog/2021/06/09/another-concepts-chest-mimic/.

Additionally, I think we could:

• Make negative-requirement a primary expression to simplify if constexpr (!requires { (t.begin()); }) to if constexpr (!requires t.begin();).
• The same for other requirements: See feat: recognize requires expressions #596 (comment).

[AbhinavK00]

( _ = T() );
{ _ = c - c } throws;

I find it weird that these use different kind of brackets. Since, compound expressions are just simple expressions with throws or is-type-requirement, they should look similar

[JohelEGP]

To simplify that, in addition to

Additionally, I think we could:

• Make negative-requirement a primary expression to simplify if constexpr (!requires { (t.begin()); }) to if constexpr (!requires t.begin();).

we could make a requires-expression's body also be a single requirement.

    //G requires-expression:
    //G     'requires' parameter-declaration-list? requirement-body
    //G     '!'? 'requires' parameter-declaration-list? requirement

requires requires(c: T) { _ = c - c; } // Long-winded spelling.
requires requires(c: T) _ = c - c;     // Simpler spelling.
requires !requires std::iter_reference_t<T>;      // OK.

To compare:

requires requires(const T& c) { c - c; } // Cpp1

requires requires(c: T) _ = c - c;     // Cpp2
requires requires(c: T) { _ = c - c; } // Cpp2

requires !requires { typename std::iter_reference_t<T>; } // Cpp1

requires !requires std::iter_reference_t<T>; // Cpp2

[AbhinavK00]

Make negative-requirement a primary expression to simplify if constexpr (!requires { (t.begin()); }) to if constexpr (!requires t.begin();)

This makes distinguishing between requires clauses and expressions even harder. In cpp1, I know that if there's no braces after requires, it will be a requires clause but if you allow this, then it can be requires clause or a requires expression in cpp2.

I would not sacrifice readability for one less pair of braces.

[JohelEGP]

A requires clause can only happen before the = of a declaration.

[AbhinavK00]

Yes, but it still can be confusing to the reader.

[JohelEGP]

I will doubt that until I find out code that makes me think so.
To me, the context dependence makes this pretty unambiguous.

[AbhinavK00]

Fair enough 👌

[JohelEGP]

I'm changing this #526's and #596's use of throws.
The default will be the same as Cpp1's,
which is the same as most authored functions.
Instead, I'll extend throws-specifier to accept !throws,
which is a shorthand for https://wg21.link/P0709's throws(false).

With that change, you won't need to add throws
when rewriting Cpp1 non-noexcept function types or expression requirements for Cpp2.
For #596, I'll be able to re-add expression-requirement as _ = 𝘌;.
Explicitly discarding the result should more naturally handle the talk's pitfalls.

[JohelEGP]

I'm thinking that this should simply be

Suggested change

	//G simple-requirement
	//G type-id ';' // Cpp1 type-requirement
	//G type-id ';' // Cpp1 type-requirement
	//G expression ';' // Cpp1 simple-requirement

Just like the rhs of is-as-expression,
potentially template arguments after resolving #727, and
potentially the lhs of is-as-expression after merging #782.

That's consistent, but would also make it easier to reintroduce the pitfalls.

// https://youtu.be/CXn02MPkn8Y?t=2337
negatable: <T> concept = requires(t: T)
{
  (-t is T); // Hopefully obviously wrong. Should be `{ -t } is T;`.
  -t is T;   // Wrong.
};

// https://youtu.be/CXn02MPkn8Y?t=2418
int_sized: <T> concept = requires(t: T)
{
  (sizeof(T) == 4); // Hopefully obviously wrong. Should be `requires (sizeof(T) == 4);`.
};
// Could also be `int_sized: <T> concept = sizeof(T) == 4;`.

// https://youtu.be/CXn02MPkn8Y?t=2455
nothrow_incrementable: <T> concept = requires(inout t: T)
{
  (noexcept(t++)); // Hopefully obviously wrong. Should be `requires noexcept(t++);` or `{ t++ } !throws;`.
};

// https://quuxplusone.github.io/blog/2021/06/09/another-concepts-chest-mimic/
has_a_but_not_b: <T> concept = requires(t: T)
{
  (a(t));
  !requires (b(t)); // In Cpp2, this works and does the correct thing.
  (!requires (b(t))); // Wrong.
};

[JohelEGP]

This can still be done for consistency.
And the pitfalls can still be prevent by going back to #588 (reply in thread).
Which means lowering -t is T; to { -t is T } -> not_boolean_testable.
We should also lower (!requires (b(t))) similarly,
or all simple-requirements as the linked comment says.

[hsutter]

Hi! Sorry it took me so long to get to this one... but this looks like it might still be current.

Is this up to date, and would you like me to review it?

[JohelEGP]

Yes, and yes, please do.

[hsutter]

This is the only regression test glitch I noticed ... ?

[JohelEGP]

Never noticed, since I don't use MSVC.
Somehow this is failing: static_assert(!test_nonthrowing_requirements<std::chrono::seconds>);.

[hsutter]

This would also need documentation -- would you add some coverage of this under /docs please?