On Sun, Sep 11, 2022 at 6:15 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>