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