On Sat, Sep 10, 2022 at 9:21 AM Михаил Найденов via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hello,
> I wrote to the author of P2279, but got no response for 10 days now.
> As for p2547, I really don't see how it can be improved to address the issue from this discussion.
>
> I have rewritten the proposal, in particular Problems is completely redone.
> Attached is the new draft.
>
> Thank You

This is a better description of the problem, but I think it's not
quite pointed enough. Or that it's slightly askew in where it's
pointing.

I particularly take issue with the idea that the remapping is inside
of the function. It isn't; the actual remapping takes place in the
customization point object/type trait.

The problem you are outlining is that every time a user wants to
invoke a mappable construct, the user must:

1. Explicitly specify syntactically that they are invoking a mappable construct.

2. Explicitly specify *which* mapping they are applying, above and
beyond the specific mapping function/metafunction they are invoking.
If you're using an iterator interface to compute a type, you must say
"std::iterator_traits" every single time.

So I would suggest rewriting it to focus on that. That is, lay out the
following case:

A: Remappable interfaces on templates are a good thing.

B: Remappable interfaces are currently implemented as a disjointed set
of ad-hoc constructs (customization points, type traits, etc) rather
than a holistic language feature.

C: This leads to a lot of syntactic noise at the site where these
interfaces are used, which leads working C++ programmers to avoid them
when they could have been used.

Item B would also be a good jumping off point into a discussion of the
issues with *defining* these remappable interfaces. Because at
present, your focus on the point-of-use kind of ignores the fact that
B also makes building such an interface quite problematic. That is,
the ad-hoc nature of the current system causes more problems than just
the ones you outline.

Also, I strongly recommend removing the "Forced free function call".
That smells of UFCS, which is basically going to poison any attempts
to deal with this problem. The sooner C++ programmers accept that
member functions aren't the totality of a type's interface, the
better.