On Sat, Nov 6, 2021 at 10:09 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

Well, that's my point. If it's easy for users to implement it themselves in
a portable fashion, and is not "vocabulary", then the bar for getting it
into the standard library is going to be very high.

If P1839 gets accepted, the above will be true, except for the (IMHO)
narrow case where the functionality is needed at compile time, where it
will still not be possible for users to implement it themselves. So in that
case, the motivation for the proposal should focus on why the functionality
is needed at compile time.

If P1839 doesn't get accepted, the argument for adding this to the standard
library is stronger.


>
> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*