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