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