This looks correct, but is this a novel normative requirement? (Or does this follow from existing wording somehow?)

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.

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.

I'll take it to LWG.

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​::​pointer and X​::​const_­pointer shall 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: "If a and b are both dereferenceable, then a == b if and only if *a and *b are bound to the same object." Per [pointer.traits.functions]/2, pointer_to returns a pointer that denotes its argument: "The first member function returns a pointer to r obtained by calling Ptr​::​pointer_­to(r) through which indirection is valid; ... ".

So: given a fancy pointer p of type T that denotes an object o, 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.

OK, if this is not a novel requirement, it sounds like explicitly listing it here would improve clarity without changing intent. Looks good.

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 *).

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.

Or I could create an LWG issue to require the pointer_to(r) == p equality if you're worried it's novel.

d2afc9a shows the original definition of r that was removed.

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.