I still think it might be better to return by value from rref-qualified
members to avoid dangling, e.g. in the following:

auto&& dangle = vector{1,2,3}[0];

And there is no need for overloading on const&&, because that would be
ridiculous, since you can not move from a const object.

I think, blindly following the pattern

  T && operator[](size_t i) &&;

is bad and not really helpful. RVO helps with that and a move-optimized
T will have the appropriate constructor.

Regards
Peter.

Michael Hava wrote on 22.07.20 11:28:
> 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

-- 
Peter Sommerlad
Better Software: Consulting, Training, Reviews
Modern, Safe & Agile C++
peter.cpp_at_[hidden]
+41 79 432 23 32