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_at_[hidden]> 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_at_[hidden]
> > <mailto:eyalroz_at_[hidden]>> 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_at_[hidden]
> > <mailto:std-proposals_at_[hidden]>
> > <mailto:std-proposals_at_[hidden]
> > <mailto:std-proposals_at_[hidden]>>>
> > > 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_at_[hidden]
> > <mailto:Std-Proposals_at_[hidden]>
> > <mailto:Std-Proposals_at_[hidden]
> > <mailto:Std-Proposals_at_[hidden]>>
> > > 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 *
> >
>