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
>