P1084R2 Today’s return-type-requirements Are Insufficient

[burblebee]

[expr.prim.req.compound] Renamed C5 to C3 in remaining example.

Fixes #2397.

[burblebee]

This branch is failing the travis checks because commit 0af79b8 (which resolves conflicts between cwg-4 and cwg-15) refers to the new grammar term /type-constraint/ which won't exist until after cwg-15 is merged. I couldn't add this commit in cwg-15 because it doesn't have the wording that needed to be changed. How to deal with this situation moving forward?

@zygoloid please ignore the failing checks. To merge this PR, squash the one "Fixup:" commit 2a38e29, and apply commit 0af79b8 after merging motions-2018-11-cwg-15.

[W-E-Brown]

Unless I'm missing something, the library parts of this paper (affecting Clause [concepts]) seem not yet to have been entered. See P1084R2, §5.2, top of page 5.

[CaseyCarter]

Unless I'm missing something, the library parts of this paper (affecting Clause [concepts]) seem not yet to have been entered.

I can prepare a commit with these changes, if it would be helpful (#2488). I'd like to fix UniformRandomBitGenerator as well, but it's not in a subclause of [concepts]. Is that too great a stretch to be termed editorial? (EDIT: I need to write a paper to cleanup all the usage in the P0896 concepts in any case - which is clearly too great a change to be editorial - so it's no great burden to cleanup UniformRandomBitGenerator in that paper as well.)

[jensmaurer]

@burblebee, Walter is right: The 5.2 changes are missing. You can use the changes in #2488, but I'd suggest that you integrate them in this pull request so that the entire paper is applied in one place (and yes, that's a "fixup").
@CaseyCarter, if you're writing a cleanup paper anyway, maybe we can postpone that? Or maybe create a separate editorial issue so that we can weigh the "editorial" property independently?

[CaseyCarter]

@CaseyCarter, if you're writing a cleanup paper anyway, maybe we can postpone that?

Yes, I'll just put it in the followup.

[zygoloid]

This note is overall a little hard to read due to the frequent switching to and from code font and the E; requires ...; construction appearing to be two separate clauses. Perhaps a different presentation would help -- maybe converting the tcode here into codeblocks, or more drastically something like:

[Example: Given a concept named X,

requires {
  { E1 } -> X;
  { E2 } -> X<A1, A2, ..., An>;
}

is equivalent to

requires {
  E1; requires X<decltype((E1))>;
  E2; requires X<decltype((E2)), A1, A2, ..., An>;
};

-- end example]

@W-E-Brown What do you think?

[W-E-Brown]

On Nov 20, 2018, at 11:46 PM, Richard Smith ***@***.***> wrote: @zygoloid commented on this pull request. In source/expressions.tex <#2450 (comment)>: > + \item + If the \grammarterm{return-type-requirement} + is of the form \tcode{->} \grammarterm{type-constraint}, then + the contextually-determined type being constrained + is \tcode{decltype((E))}. + The immediately-declared constraint\iref(temp) of \tcode{decltype((E))} + shall be satisfied. + \begin{note} + Thus, constraints of the form + \tcode{\{ E \} -> Concept;} or of the form + \tcode{\{ E \} -> Concept<>;} are equivalent to + \tcode{E; requires Concept<decltype((E))>;} + while a constraint of the form + \tcode{\{ E \} -> Concept<A$_1$, A$_2$, . . . , A$_n$>;} is equivalent to + \tcode{E; requires Concept<decltype((E)), A$_1$, A$_2$, ..., A$_n$>;}. + \end{note} This note is overall a little hard to read due to the frequent switching to and from code font and the E; requires ...; construction appearing to be two separate clauses. Perhaps a different presentation would help -- maybe converting the tcode here into codeblocks, or more drastically something like: [Example: Given a concept named X, requires { { E1 } -> X; { E2 } -> X<A1, A2, ..., An>; } is equivalent to requires { E1; requires X<decltype((E1))>; E2; requires X<decltype((E2)), A1, A2, ..., An>; }; -- end example] @W-E-Brown <https://github.com/W-E-Brown> What do you think?

The "drastic" reformulation seems okay to me, stylistically, although my preference would be to use C (instead of X) for the concept name. Also, CWG seemed to consider A's subscripts important here, so let's please keep those. Note that the reformulation omits the code version with the empty angle brackets. That's probably worth keeping. The earlier suggestion re use of \cdots, too, seems reasonable for these contexts.