On Fri, Nov 5, 2021 at 10:48 PM Michael Scire via Std-Proposals
<std-proposals_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?

I fail to see what P1839 has to do with *any* of this. It's a proposal
for standard library functionality. It's important to point out that,
with the current standard, there's no way for user-code to implement
it. But that's more a matter of the motivation for the proposal than
anything else (that is, it could be considered more important to add
*because* users can't implement it).

Any implementation you provide is, at best, a non-normative
suggestion. The actual normative wording will be of the form "here's
the function declaration, and here's what happens when you call it".

That having been said, I would also want to see some discussion of how
this might interact with any active reflection proposals. I haven't
seen much movement publicly on reflection lately from papers, so I'm
not sure how much this might interfere with any eventual proposals in
that domain. This is definitely playing in the same area though.

> 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);

If the member pointer is a template parameter, then this could only
work on compile-time `constexpr` member pointers. So if you're in code
where you take a member pointer as a function parameter, you couldn't
call it.

So it's probably best to not force it to be compile-time only like that.