C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] Language Feature for Reducing Duplicated Code
From: Eyal Rozenberg (eyalroz_at_[hidden])
Date: 2020-07-29 15:33:00


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


STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups