Per discussion at #565 (review).
Generally I believe that there should be a bigger focus on readability of the concepts. Currently a lot of the more complex concepts are really hard to grog due to unfortunate formatting. I believe that we would gain a lot by spending a few lines more to improve the general readability.
I agree. I've been trying to format the constraint-expressions in concepts as clang-format would - with the expectation that it will reduce churn someday when clang-format learns to understand concepts and requires-clauses - but I've started cheating here and there when it helps readability. We should simply go all in and format them one-term-per-line (except for very simple cases) as in the Ranges TS.
I'll update the concept definitions that this PR touches, and file an issue to make a general audit.
We should audit all concept definitions for readability. Some guidelines:
- The first line of the definition may contain multiple terms if they aren't too complex visually.
- Try not to split disjunctions across multiple lines if possible (we prefer Conjunctive Normal Form)
- Continuation lines should generally have a single term, although there are exceptional cases where multiple terms can better convey structure. For example:
template <class _Ty>
concept copy_constructible = move_constructible<_Ty>
&& constructible_from<_Ty, _Ty&> && convertible_to<_Ty&, _Ty>
&& constructible_from<_Ty, const _Ty&> && convertible_to<const _Ty&, _Ty>
&& constructible_from<_Ty, const _Ty> && convertible_to<const _Ty, _Ty>;
- Terms with many and/or complex arguments can be split across multiple lines:
template <class _Fn, class _It>
concept indirectly_unary_invocable = indirectly_readable<_It>
// ...snip...
&& common_reference_with<
invoke_result_t<_Fn&, iter_value_t<_It>&>,
invoke_result_t<_Fn&, iter_reference_t<_It>>>;
Per discussion at #565 (review).
We should audit all concept definitions for readability. Some guidelines: