On Fri, Nov 5, 2021 at 10:48 PM Michael Scire via Std-Proposals
<std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals