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] <http://eel.is/c++draft/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_at_[hidden]
> <mailto: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 <http://macieira.info>
> - thiago (AT) kde.org <http://kde.org>
> Software Architect - Intel DPG Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>