General ufcs without an opt-in breaks code. A lot of code. And some of it not even with a compile error, just differences in behavior.

This would have been a python2->python3 style incompatibility that would fragment the user-base and cause developer-millenia of grief and churn for a fairly minor benefit.

Therefore, regardless of the utility, it's a non-starter. 

Opt-in ufcs, if we even get it, allows a type author to easily enable an interface for use with both styles to aid generic programming (more free-function based) while allowing member-call for non-generic contexts where member call is more readable.

G

On Wed, Jul 29, 2020, 21:33 Eyal Rozenberg <eyalroz@technion.ac.il> wrote:
I know that Uniform Call Syntax was met with resistance. That's
unfortunate, I really did not buy the arguments against it. The
"explicit opt-in" is not useful enough and will IMHO all but ensure lack
of adoption of the feature. The whole point - again IMHO - is shifting
the language's view of what a method call is to eventually being simply
syntactic sugar around a regular standalone function call, plus maybe a
vtable lookup.

But never mind, this is too much of a digression from the original
discussion.

On 22/07/2020 15:43, Gašper Ažman wrote:
> 1) deducing this *does* piggyback on the existing free-function
> mechanisms for deduction. That's practically the entire point - we don't
> have to change any template wording at all.
> 2) UFCS is a non-starter - unless you introduce explicit opt-in syntax
> for it. We have UNPROPOSED ideas on that front:
> struct Foo {
>      friend void func(this Foo&) {} // friend + explicit this parameter
> = callable both ways
> };
> but they require that one first introduces the explicit designation
> anyway. It's also not guaranteed that EWG will agree that this is even
> desirable. We did think about it, though, and tried to make sure it's
> possible to go there in the future if that's where the language wants to go.
>
> G
>
>
> On Wed, Jul 22, 2020 at 1:00 PM Eyal Rozenberg <eyalroz@technion.ac.il
> <mailto:eyalroz@technion.ac.il>> wrote:
>
>     Gasper, would this proposal be obviated/simplified if we had uniform
>     call syntax? i.e. wouldn't it make more sense to piggy-back onto the
>     existing standalone function mechanisms for deduction?
>
>     Eyal
>
>     On 18/07/2020 10:42, Gašper Ažman via Std-Proposals wrote:
>      > Already in the pipeline - deducing this.
>      >
>     http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0847r4.html
>     <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2020%2Fp0847r4.html&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C2067154d08a94af9bc8608d82e3ccd96%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637310185991247494&sdata=vfqtxlzc%2FirH2R0gdAF8tiJhOJHAwkAsOqrQzZyfCV4%3D&reserved=0>
>
>      >
>     <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2020%2Fp0847r4.html&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C15372fb1708a49a39f8108d82aee45c9%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637306550155471017&sdata=bChBVJ%2BMAihDzWY7Bmh3NdBBOMk54bQ4SjuESo0wySo%3D&reserved=0
>     <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2020%2Fp0847r4.html&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C2067154d08a94af9bc8608d82e3ccd96%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637310185991247494&sdata=vfqtxlzc%2FirH2R0gdAF8tiJhOJHAwkAsOqrQzZyfCV4%3D&reserved=0>>
>
>      >
>      >
>      > It's well on track for acceptance.
>      >
>      > On Sat, Jul 18, 2020, 06:29 David Ledger via Std-Proposals
>      > <std-proposals@lists.isocpp.org
>     <mailto:std-proposals@lists.isocpp.org>
>     <mailto:std-proposals@lists.isocpp.org
>     <mailto:std-proposals@lists.isocpp.org>>>
>      > wrote:
>      >
>      >     Hello Everyone,
>      >
>      >     Duplicate function bodies seem to exist everywhere in C++
>     codebases.
>      >     This attempts to reduce duplicate code by allowing deduction of
>      >     const for a function. Allowing a const and non-const function to
>      >     have the same function body but call the appropriate const or
>      >     non-const functions.
>      >
>      >     What I'm talking about it that everyone writes:
>      >
>      >              iterator begin();
>      >              iterator begin() const;
>      >
>      >              T & operator[](size_t i);
>      >              T const  & operator[](size_t i) const;
>      >
>      >     Same for operator[] and function at, and begin, end, front,
>     back etc...
>      >
>      >     For the const and non-const versions of the function, often
>     the body
>      >     of these functions is identical, all that changes is the
>     return type
>      >     and the selected overloads in the function body. I don't
>     really see
>      >     the benefit for this and want to improve this.
>      >
>      >     So I want to propose the following:
>      >
>      >              const(auto),
>      >              const(boolean expr)
>      >
>      >              noexcept(auto), we already have noexcept(boolean expr)
>      >
>      >     This would let me write:
>      >
>      >              iterator begin() const(auto);
>      >
>      >     The problem this introduces is how is the return type determined
>      >     here, well to do that we would need the bool available for
>     the user:
>      >
>      >              abbreviated syntax:
>      >              auto begin() const(is_const) -> iterator<is_const>;
>      >
>      >     or,
>      >
>      >              template syntax:
>      >              template <bool is_const>
>      >              auto begin() const(is_const) -> iterator<is_const>;
>      >
>      >     or,
>      >
>      >              template syntax with return using conditional_t
>      >              auto begin() const(is_const) -> conditional_t<is_const,
>      >     citerator, iterator>;
>      >
>      >     There are additional benefits here:
>      >     - Keep function logic in one place, not many.
>      >     - Use template parameters of a class to fully const or
>     not-const all
>      >     functions in a class.
>      >     - Reduce the maintenance cost of std library code by halving (in
>      >     some cases) the number of overloads.
>      >
>      >     As I see it, what needs to be solved:
>      >     - Member function pointers, how to get an exact one?
>      >
>      >     I'm happy to write up a proposal for this to submit.
>      >     Anyone have and feedback before I write it up?
>      >
>      >     Regards,
>      >           David Ledger
>      >     --
>      >     Std-Proposals mailing list
>      > Std-Proposals@lists.isocpp.org
>     <mailto:Std-Proposals@lists.isocpp.org>
>     <mailto:Std-Proposals@lists.isocpp.org
>     <mailto:Std-Proposals@lists.isocpp.org>>
>      > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>     <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C2067154d08a94af9bc8608d82e3ccd96%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637310185991257492&sdata=rARAHPyudM4tYnCQIFoiJvsSLOoAyLIq%2BY7HrZ6QXuE%3D&reserved=0>
>      >   
>       <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C15372fb1708a49a39f8108d82aee45c9%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637306550155481012&sdata=J06Nj5UH%2B2nl%2BO0lJ%2F7tUGQuhHINDtKoOXtbdyUdgOo%3D&reserved=0 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=02%7C01%7Ceyalroz%40ef.technion.ac.il%7C2067154d08a94af9bc8608d82e3ccd96%7Cf1502c4cee2e411c9715c855f6753b84%7C1%7C0%7C637310185991257492&sdata=rARAHPyudM4tYnCQIFoiJvsSLOoAyLIq%2BY7HrZ6QXuE%3D&reserved=0>>
>      >
>      > *This email is from an external mail server, be judicious when
>     opening
>      > attachments or links *
>      >
>      >
>
> *This email is from an external mail server, be judicious when opening
> attachments or links *
>