On Sun, Sep 11, 2022 at 6:15 PM Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Sat, Sep 10, 2022 at 9:21 AM Михаил Найденов via Std-Proposals
<std-proposals@lists.isocpp.org> 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.
 
Sure, this is what makes modern generic programming "advanced". Added an extra line.  

I also added a paragraph describing a viewpoint regarding "customization points" in general


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.

I believe "atomic grouping" in  P2279 covers that already and indeed point-of-use/user experience/"look and feel" is the main focus.

And this is why I can't really ignore the move to free function call - it would not be honest to ignore the expectations in that direction.
Regular code, template code, other languages - there is an expectation, member notation can be used.

Hopefully, we will not fall into UCF debate. It seems certain at this point, there will be a mapping layer, one way or another.
Any call will still be to that mapping, not to concrete type. Ultimately, we need a better way to define, and a natural way to call that mapping,
not a way to extend existing types. Hopefully, again, this will also keep us away from failed approaches like concept_maps.


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