Date: Wed, 22 Jul 2020 10:36:57 +0100
Isn't it wonderful that deducing this makes the above SO much easier to do?
On Wed, Jul 22, 2020 at 10:28 AM Michael Hava via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> And while we are at it:
> Operations that return references to internals of an object should also be
> rvalue-ref-qualified, as there is no reason one shouldn't be able to move
> the guts out of a temporary...
>
> T & operator[](size_t i) &;
> const T & operator[](size_t i) const &;
> T && operator[](size_t i) &&;
> const T && operator[](size_t i) const &&;
>
> Matching what we already do with std::get for array/pair/tuple/variant ...
>
> > -----Original Message-----
> > From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf
> Of
> > Peter Sommerlad (C++) via Std-Proposals
> > Sent: Wednesday, July 22, 2020 9:10 AM
> > To: David Ledger via Std-Proposals <std-proposals_at_[hidden]>
> > Cc: Peter Sommerlad (C++) <peter.cpp_at_[hidden]>
> > Subject: Re: [std-proposals] Language Feature for Reducing Duplicated
> Code
> >
> > David,
> >
> > You are missing the ref-qualification.
> >
> > I always argue that member functions returning the guts of an object or a
> > reference to *this should be lvalue-ref qualified to make sure they are
> not
> > called on temporaries, because that would lead to immediate dangling. So
> > your examples (in my book) should be
> >
> > iterator begin() &;
> > iterator begin() const &;
> > >
> > T & operator[](size_t i) &;
> > T const & operator[](size_t i) const &;
> >
> > Just my 0.02CHF
> >
> > Peter.
> >
> > David Ledger via Std-Proposals wrote on 18.07.20 07:29:
> > > 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
> > >
> >
> >
> > --
> > Peter Sommerlad
> >
> > Better Software: Consulting, Training, Reviews Modern, Safe & Agile C++
> >
> > peter.cpp_at_[hidden]
> > +41 79 432 23 32
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
On Wed, Jul 22, 2020 at 10:28 AM Michael Hava via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> And while we are at it:
> Operations that return references to internals of an object should also be
> rvalue-ref-qualified, as there is no reason one shouldn't be able to move
> the guts out of a temporary...
>
> T & operator[](size_t i) &;
> const T & operator[](size_t i) const &;
> T && operator[](size_t i) &&;
> const T && operator[](size_t i) const &&;
>
> Matching what we already do with std::get for array/pair/tuple/variant ...
>
> > -----Original Message-----
> > From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf
> Of
> > Peter Sommerlad (C++) via Std-Proposals
> > Sent: Wednesday, July 22, 2020 9:10 AM
> > To: David Ledger via Std-Proposals <std-proposals_at_[hidden]>
> > Cc: Peter Sommerlad (C++) <peter.cpp_at_[hidden]>
> > Subject: Re: [std-proposals] Language Feature for Reducing Duplicated
> Code
> >
> > David,
> >
> > You are missing the ref-qualification.
> >
> > I always argue that member functions returning the guts of an object or a
> > reference to *this should be lvalue-ref qualified to make sure they are
> not
> > called on temporaries, because that would lead to immediate dangling. So
> > your examples (in my book) should be
> >
> > iterator begin() &;
> > iterator begin() const &;
> > >
> > T & operator[](size_t i) &;
> > T const & operator[](size_t i) const &;
> >
> > Just my 0.02CHF
> >
> > Peter.
> >
> > David Ledger via Std-Proposals wrote on 18.07.20 07:29:
> > > 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
> > >
> >
> >
> > --
> > Peter Sommerlad
> >
> > Better Software: Consulting, Training, Reviews Modern, Safe & Agile C++
> >
> > peter.cpp_at_[hidden]
> > +41 79 432 23 32
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2020-07-22 04:40:58