On Thursday, March 10th, 2022 at 4:19 AM, Paolo Di Giglio <p.digiglio91_at_[hidden]> wrote:

> Thanks @Arthur and @Zhihao.
>

> About these two comments:
>

> > You can (and should) std::move(arr[Idx]).
>

> and
>

> > Because of everything you said about MSVC, I suggest that your proposal
>

> > (and vendors' implementations too) should actually say
>

> >
>

> > return std::move(arr[Idx]); // correct in practice
>

> >
>

> > not
>

> >
>

> > return std::move(arr)[Idx]; // pedantically correct but fails on MSVC
>

> >
>

> > The effect is the same, on everything-but-MSVC; and on MSVC the former
>

> > is preferable. (AFAIK, both are equally correct as far as the paper
> > standard is concerned.)
>

> I can't understand whether there's a real difference in either of the
>

> return statements if the return type of std::get is T&&. I'd expect an
> implicit cast to T&& on MSCV (and no cast on other compilers).

Lvalue doesn't bind to T&&, andMSVC did not implement arrayrvalues correctly:

https://developercommunity.visualstudio.com/t/Wrong-type-deduction-for-rvalue-referenc/1067691
https://developercommunity.visualstudio.com/t/Subscript-expression-with-an-rvalue-arra/1317259

But other than the built-in array,no operator[] in the standard isaware of value-category (std::array,std::vector, etc.) The built-inarray is special here as its "[i]"models after a member access.

--Zhihao Yuan, ID lichray

The best way to predict the future is to invent it.

_______________________________________________