> In addition, there aren't standard facilities for getting the parent and member types from a pointer-to-member. These are trivial to write, but without them what would be the way to specify the types that I mean in a proposal?

As I understand it, it's common to have "exposition only" facilities often "named-like-this" that are used in the standard but not part of the exposed API.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 5th, 2021 at 9:47 PM, Michael Scire via Std-Proposals <std-proposals_at_[hidden]> wrote:

> So, if I wanted to write a formal proposal, what kinds of things should I take into account?
>
> It sounds like there are multiple -- is Brian's comment that I should describe both the case where P1839 is accepted and not good advice?
>
> If I was drafting it I would kind of prefer for this not to fundamentally block on another proposal, if possible, but I would like to follow best practice.
>
> Which of the following forms seems preferable?
>
> template<auto MemberPtr> // Participates in overload resolution only if std::is_member_object_pointer_v<decltype(MemberPtr)>
> /* Parent Type */ &parent_of_member(/* Member type */ &member);
>
> or
>
> template<class T> // Participates in overload resolution only if std::is_member_object_pointer_v<decltype(MemberPtr)>
> /* Parent Type */ &parent_of_member(T const &pmd, /* Member type */ &member);
>
> In addition, there aren't standard facilities for getting the parent and member types from a pointer-to-member. These are trivial to write, but without them what would be the way to specify the types that I mean in a proposal?
>
> I would normally do e.g.
>
> template<auto MemberPtr> requires std::is_member_object_pointer_v<decltype(MemberPtr)>
> struct member_pointer_traits;
>
> template<typename Parent, typename Member, Member Parent::*MemberPtr>
> struct member_pointer_traits<MemberPtr> {
> using parent_type = Parent;
> using member_type = Member;
> };
>
> But I'm not sure how I would specify these types in a proposal, and I don't have any particular interest in adding such helpers to the standard.
>
> On Fri, Nov 5, 2021 at 6:42 PM Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> On Friday, 5 November 2021 17:26:17 PDT Lénárd Szolnoki via Std-Proposals
>> wrote:
>>> I don't think a non-UB implementation is possible here. I have the
>>> impression that the pointer to the parent type is intentionally unreachable
>>> and in theory compilers are allowed to optimize based on that.
>>
>> But that's irrelevant.
>>
>> If the paper proposing such a functionality is accepted and added to
>> <type_traits>, *how* the implementation implements it is the implementation's
>> own problem. They may need to add an intrinsic or magic to make it happen, so
>> the compiler never accidentally mis-optimises it because it thinks it's UB.
>>
>> Your use of a std functionality in a way permitted by the standard is not UB.
>> Copying such an implementation to your own code may be.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel DPG Cloud Engineering
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals