On 06/11/2021 03:42, Michael Scire via Std-Proposals wrote:
> Is that to suggest the whole proposal is a no-go, then?

No. To suggest that implementing something like parent_of_member in «conforming C++» would require more changes than P1839R2 introduces.
It is a question to compiler developers: how much they rely on the fact that one can't, in general, go from a member subobject to its containing object and if they do, do they want to stop relying on this.
  
> I'm not sure -- it seems okay to me if there's no user-writable way to
> perform such offsetof arithmetic, if there's a compiler-magic way to do the
> pointer-of-member I'm interested in.
>
> Certainly I think that parent of member is a pretty useful operation at
> runtime that it would be nice to be able to write without UB.
>
> On Fri, Nov 5, 2021 at 5:35 PM language.lawyer--- via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On 06/11/2021 03:12, Brian Bi via Std-Proposals wrote:
>>> `reinterpret_cast<uintptr_t>(std::addressof(reinterpret_cast<ParentType
>>> *>(0)->*member_ptr))` is UB. You have to use the magic `offsetof` macro.
>>> P1278 <http://wg21.link/p1278> proposes to add a similar non-macro
>> facility.
>>>
>>> The problem is how to then perform the pointer arithmetic and convert the
>>> result into a pointer to the parent type. This cannot be done in user
>> code
>>> in C++17, so even at runtime, it would require compiler magic. If P1839
>>> <http://wg21.link/P1839> gets accepted, it will be possible to
>> implement it
>>> in user code.
>>
>> I think this has already been discussed in this mail list: it won't be
>> possible.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>
>