[range.prim.size] rewords p1.3 to make it easier to parse #3565
Conversation
There was a problem hiding this comment.
I've reworded this paragraph so many times that I have no perspective anymore as to what's better or worse, but I can at least attest this change doesn't damage the paragraph (with @JohelEGP's suggested change).
Co-Authored-By: Johel Ernesto Guerrero Peña <johelegp@gmail.com>
| Otherwise, \tcode{\placeholdernc{make-unsigned-like}(ranges::end(E) - ranges::begin(E))}\iref{ranges.syn} | ||
| if it is a valid expression, and | ||
| \tcode{T} models \tcode{forward_range}\iref{range.refinements}, and | ||
| \tcode{iterator_t<T>} and \tcode{sentinel_t<T>}\iref{ranges.syn} model |
There was a problem hiding this comment.
No two cross-references to the same place within the same paragraph, please.
| Otherwise, \tcode{\placeholdernc{make-unsigned-like}(ranges::end(E) - ranges::begin(E))}\iref{ranges.syn} | ||
| if it is a valid expression, and | ||
| \tcode{T} models \tcode{forward_range}\iref{range.refinements}, and | ||
| \tcode{iterator_t<T>} and \tcode{sentinel_t<T>}\iref{ranges.syn} model |
There was a problem hiding this comment.
How editorially-obvious is it that iterator_t<T> and the type of ranges::begin(E) are actually the same type? For example, could ranges::begin(E) return an lvalue, which would make iterator_t<T> a reference? (i think the answer is "no", because weakly_incrementable requires default-constructible. And the answer is also "no" for the similar question regarding ranges::end(E), because semiregular also requires default-constructible. But it takes a few hops to get there.)
There was a problem hiding this comment.
No, they cannot return references. They either return a pointer, or decay-copy(something).
zygoloid
added
the
needs rebase
|
Please rebase and force-push. |
tkoeppe
added
the
changes requested
|
@cjdb: Ping, are you still interested in this PR? |
|
I'm not sure why this got closed; it wasn't meant to be. |
|
@jensmaurer, @jwakely, @CaseyCarter: are you interested in taking this further? You can check out the last commit via |
I expressed a desire to reword [range.prim.size] p1.3 on the LWG reflector, as I felt it is currently difficult to grasp the exact requirements (from an implementer's point-of-view). Hopefully this wording conveys the necessary requirements in a more concise manner.
Little feedback was given, so I'm unsure if this is something that should first go through a full review in Prague.