Er, the second form would participate only if
std::is_member_object_pointer_v<T>, sorry about the copy paste error and
about the second e-mail to correct that.

On Fri, Nov 5, 2021 at 7:47 PM Michael Scire <sciresm_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
>>
>