Date: Thu, 10 Mar 2022 15:24:55 +0100
Il 10/03/22 13:22, Paolo Di Giglio via Std-Proposals ha scritto:
>
> > 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). Am I
> missing something here?
That MSVC is bugged (non-conforming), so any "reasoning" about its
behavior is impossible. The result of operator[] on an xvalue array is
an xvalue https://eel.is/c++draft/basic.lval#4.3 , but MSVC deduces the
wrong type:
> int a[] = {1, 2, 3};
> static_assert(std::is_same_v<decltype(std::move(a)[1]), int&&>); // ERROR on MSVC
You shouldn't worry about this at all in a specification, I'd just
re-use the wording from things such as to_array(T (&&)[N]).
My 2 c,
>
> > 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). Am I
> missing something here?
That MSVC is bugged (non-conforming), so any "reasoning" about its
behavior is impossible. The result of operator[] on an xvalue array is
an xvalue https://eel.is/c++draft/basic.lval#4.3 , but MSVC deduces the
wrong type:
> int a[] = {1, 2, 3};
> static_assert(std::is_same_v<decltype(std::move(a)[1]), int&&>); // ERROR on MSVC
You shouldn't worry about this at all in a specification, I'd just
re-use the wording from things such as to_array(T (&&)[N]).
My 2 c,
-- Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
Received on 2022-03-10 14:25:00