On 11/5/21 10:47 PM, Michael Scire via Std-Proposals wrote:
So, if I wanted to write a formal proposal, what kinds of things should I take into account?

With regard to naming, "parent" is not a term the standard uses to refer to the class of which a declared member is a member, nor to an object of which a member is a subobject. That suggests that "parent_of_member" is not the most suitable name for this function.

The intent is to return a reference to an object that contains the provided object (which necessarily must be a member subobject). I believe the terminology used to describe these relationships in [intro.object] is your best bet for finding a suitable name. Perhaps std::object_containing_member() or std::containing_object_of().

Note that an array element is a member subobject of the array of which it is an element. The function you are proposing should not attempt to support this relationship (since there is no array element analog to pointer to member type that makes the offset calculation possible). I only point this out because the existing terminology is also used to cover this case. The suggested std::is_member_object_pointer_v constraint seems correct.

Tom.


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