[inplace.vector] Use T*, not pointer, for some return types

[Quuxplusone]

This is editorial for now. But P3160 "allocator-aware inplace_vector" might change the definition of pointer (that's still up in the air), and if so, we definitely want try_emplace_back to continue returning a raw pointer, not some kind of fancy pointer. Make that change now, so that we don't have to worry about it during the discussion of P3160.

Marking as "draft" until @phalpern confirms that this is desirable (or at least not harmful) from his POV too.

[jensmaurer]

At the present stage, this change feels undermotivated to me (as an editorial change). The paper changing the pointer typedef should make a case why the three try_ functions should always return a raw pointer. And the diff for these just three functions seems small enough not to cause excessive clutter.

[phalpern]

If pointer and const_pointer are changed to be related to the allocator, then I'm unclear whether the try_emplace function should return a raw pointer or a pointer, since it's unclear what the pointer and const_pointer types are supposed to indicate. If they indicate a pointer type that can address any element of the container, then perhaps try_emplace should be left alone, since it returns a (nullable) pointer to an element. I'm in favor of deprecating pointer and const_pointer for all containers, since their purpose is unclear. If that happens, then changing try_emplace (and any other function that might return pointer) makes obvious sense. I am neutral about making the change to try_emplace in isolation, with no change to pointer or const_pointer.

[frederick-vs-ja]

I'm in favor of deprecating pointer and const_pointer for all containers, since their purpose is unclear.

I'm also for deprecation. As of C++23, the pointer member typedef can make some containers automatically "usable" with out_ptr_t/inout_ptr_t, which is extremely accidental to me.