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.

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.

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.

In the current working paper, pointer is T*, so I take it we don't need this?

In the current working paper, pointer is T*, so I take it we don't need this?

Yeah. But I think the intent is making the return types of try_* functions robust to potential change of pointer. The changes are still editorial currently, but will be possibly not so in the future.

Let's have such changes when/if LWG / LEWG does decide to change the definition of "pointer". Then it's intentional what the try_ functions should return, by adapting this then.

@jwakely , is there some LWG-level motivation to have this changed editorially?

In the current working paper, pointer is T*, so I take it we don't need this?

This has always been editorial, so yeah, we "don't need" any editorial change, by definition. The original motivation here was to front-load this editorial change in order to minimize P3160's diff (exactly the motivation @jensmaurer just gave, except, front-loading the intentionality: we commit up front that we really do want the current behavior, T*, here, rather than leaving that up in the air until later: force an explicit change here if someone wants to change that behavior).

That said, P3160 is abandoned/rejected at this point, so unless it comes back as a result of NB comment, the only motivation to prefer T* over pointer here is simplicity of specification.

There are likely a lot of places where we could replace a use of a local typedef with a template parameter, and it would be editorial, so if the answer to "why do it here" is "because that's the intention of future paper X", then the right approach is to have future paper X do it, to explicitly surface that intentionality in the wording diff (even though that makes the diff slightly larger).