> 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@lists.isocpp.org> 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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals