[out.ptr.t][inout.ptr.t] The notes for `operator void**` might suggest violation of the strict aliasing rule

[frederick-vs-ja]

The suggested implementation strategy can make the stored Pointer member subobject modified via a void* lvalue, which violates the strict aliasing rule ([basic.lval]/11), and might result in miscompilation on compilers that make use of TBAA.
A std::byte array member of appropriate size and alignment is suitable for the required type punning due to implicit object creation (the destructor can read p by std::bit_cast if the such strategy is used).

As the strategy using a byte array may be too delicate for a note, can we just remove the notes, or replace the wording with a less detailed one?
(E.g. Recommended practice: If possible, implementations should use no additional storage with respect to that for p in order to support both conversion functions.)

[jensmaurer]

The TBAA violation was known when the paper was approved by LWG.

@jwakely , do you think there is anything we can do to this note to make it palatable?

[timsong-cpp]

I think this is why we used "can be" rather than "is" - it can be viable on non-TBAA implementations. For some implementations it's not a viable implementation strategy, whether because of TBAA or something else (e.g., void* might not have the same size and alignment as Pointer).

[jwakely]

The main motivation for that member is to interoperate with APIs doing disgusting aliasing violations. The motivating examples in the paper involve aliasing violations, but that doesn't happen inside the standard library. If users choose to pass the void** to something that misuses it, that's not the library's problem, and it's exactly what they'd be doing today without the std::out_ptr utility.

[timsong-cpp]

The main motivation for that member is to interoperate with APIs doing disgusting aliasing violations. The motivating examples in the paper involve aliasing violations, but that doesn't happen inside the standard library. If users choose to pass the void** to something that misuses it, that's not the library's problem, and it's exactly what they'd be doing today without the std::out_ptr utility.

We intentionally worded this to make the behavior well-defined even for what would otherwise have been disgusting aliasing violations though - that's why we didn't just specify this as returning the result of reinterpret_cast.

[frederick-vs-ja]

Can we add "for some compilers" to indicate that such strategy is not always viable?
Users may write analogies of these types, IMO it should be noted that the strategy is not portable.

[jensmaurer]

We tend to avoid the term "compiler" in the standard; some of the existing uses would benefit from replacement by "implementation" or similar.