[allocator.requirements] Fix pointer_to expression #1656
Conversation
|
Looks good to me. |
|
Go for it. |
| \tcode{pointer_traits<\brk{}X::pointer\brk{}>::pointer_to(*p)} & | ||
| \tcode{X::pointer} & | ||
| & \\ \rowsep | ||
| same as \tcode{p} & \\ \rowsep |
There was a problem hiding this comment.
This looks correct, but is this a novel normative requirement? (Or does this follow from existing wording somehow?)
There was a problem hiding this comment.
If pointer_to is not the inverse of *p then pointer_to is unusable for the purpose it was designed for. Formally, pointer_to(*p) returns a pointer to *p, and I can't imagine a sane pointer-like type where that pointer isn't equal to p. Maybe it should be stated in terms of equality, rather than "same as".
Or we could simply define r before the table.
There was a problem hiding this comment.
It sounds like you're saying this is a novel normative requirement, but is one that was intended to be required and omitted, right? If you say this does not need LWG review, I'll take your word for that, but my inclination would be to run this past LWG.
There was a problem hiding this comment.
I raised this on the lib reflector and @CaseyCarter cleverly pointed out:
Per [allocator.requirements]/5, an allocator's pointer types must meet the random access iterator requirements: "
X::pointerandX::const_pointershall also satisfy the requirements for a random access iterator and of a contiguous iterator." Random access iterators must satisfy the forward iterator requirements. Per [forward.iterators]/6, two forward iterators that denote the same object must be equal: "Ifaandbare both dereferenceable, thena == bif and only if*aand*bare bound to the same object." Per [pointer.traits.functions]/2,pointer_toreturns a pointer that denotes its argument: "The first member function returns a pointer torobtained by callingPtr::pointer_to(r)through which indirection is valid; ... ".
So: given a fancy pointer
pof typeTthat denotes an objecto,std::pointer_traits<T>::pointer_to(*p) == p.
The trail is a bit subtle. Perhaps a note would help?
So it's not a novel requirement, it's already there if you look hard enough. The part I was missing was "a == b if and only if *a and *b are bound to the same object" which forbids fancy pointers from having other "salient attributes" that determine equality, only the identity of the pointee determines equality.
There was a problem hiding this comment.
OK, if this is not a novel requirement, it sounds like explicitly listing it here would improve clarity without changing intent. Looks good.
source/lib-intro.tex
Outdated
| \tcode{static_cast<} \tcode{X::const_pointer\brk{}>(x) == q} & \\ \rowsep | ||
|
|
||
| \tcode{pointer_traits<\brk{}X::pointer\brk{}>::pointer_to(r)} & | ||
| \tcode{pointer_traits<\brk{}X::pointer\brk{}>::pointer_to(*p)} & |
There was a problem hiding this comment.
I'm a little worried that this can be interpreted as only applying to a construct of this form (ie, not applying to the case of pointer_traits<X::pointer>::pointer_to(r) for an arbitrary lvalue r of the right type). Eg, when we place requirements on *r++ in the input iterator requirements, the user is not permitted to draw conclusions from that about the expression r++ (without the *).
There was a problem hiding this comment.
OK, we could introduce r before the table, as being the object that *p yields, so we can keep the requirement that pointer_to(r) == p.
There was a problem hiding this comment.
Or I could create an LWG issue to require the pointer_to(r) == p equality if you're worried it's novel.
There was a problem hiding this comment.
d2afc9a shows the original definition of r that was removed.
There was a problem hiding this comment.
I see. So even the old formulation would have carried the implication that only *p can be used here. Let's reintroduce r to retain the modicum of indirection between the syntax here and the *p.
|
New patch coming soon ... |
|
Rebased and modified to address review comments from @zygoloid |
4 participants
Fixes #1592