Date: Wed, 4 Jun 2025 14:41:45 -0500
> "moving" meaning "using std::move" meaning casting to an rvalue
reference, let's not point such things out when we know what we are talking
about :/
I'm a bit confused about what you're talking about. Std::move does not, in
and of itself, move anything.
What you're proposing with std::move_as<V>(u) doesn't really make sense
either. It doesn't make sense to move a type U as another unrelated type V.
What you want is to construct a V from std::move(u), which is what
V(std::move(u)) already says.
Jeremy
On Wed, Jun 4, 2025 at 4:14 AM Tymi via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> "moving" meaning "using std::move" meaning casting to an rvalue reference,
> let's not point such things out when we know what we are talking about :/
>
>
> > I don't think your std:: expected example works, it didn't have a
> conversion operator. What you want is just std:: move(*exp) or
> *std::move(exp).
>
> My std::expected example does not currently work, but std::move_as opens a
> possibility for std::expected to implement such a conversion.
> std::move(*myExpected) works, but std::move_as<Value>(myExpected) seems
> cleaner to me.
>
> > And your string example works with just static_cast<std::string&&>(obj).
>
> And no, static_cast<std::string&&>(obj) does not work.
> On 04.06.2025 11:08, Jonathan Wakely wrote:
>
>
>
> On Wed, 4 Jun 2025, 09:03 Tymi via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> I find the move_as example more intuitive and generally "safer". Also my
>> first thought was that std::string(std::move(c)) copied c._value and
>> created a new object out of it, instead of just moving c._value.
>>
>
> You seem to be saying "moving" when you mean "casting to rvalue
> reference", which is not moving.
>
>
> I don't think your std:: expected example works, it didn't have a
> conversion operator. What you want is just std:: move(*exp) or
> *std::move(exp).
>
> And your string example works with just static_cast<std::string&&>(obj).
>
> So I think the existing solutions are fine.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
reference, let's not point such things out when we know what we are talking
about :/
I'm a bit confused about what you're talking about. Std::move does not, in
and of itself, move anything.
What you're proposing with std::move_as<V>(u) doesn't really make sense
either. It doesn't make sense to move a type U as another unrelated type V.
What you want is to construct a V from std::move(u), which is what
V(std::move(u)) already says.
Jeremy
On Wed, Jun 4, 2025 at 4:14 AM Tymi via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> "moving" meaning "using std::move" meaning casting to an rvalue reference,
> let's not point such things out when we know what we are talking about :/
>
>
> > I don't think your std:: expected example works, it didn't have a
> conversion operator. What you want is just std:: move(*exp) or
> *std::move(exp).
>
> My std::expected example does not currently work, but std::move_as opens a
> possibility for std::expected to implement such a conversion.
> std::move(*myExpected) works, but std::move_as<Value>(myExpected) seems
> cleaner to me.
>
> > And your string example works with just static_cast<std::string&&>(obj).
>
> And no, static_cast<std::string&&>(obj) does not work.
> On 04.06.2025 11:08, Jonathan Wakely wrote:
>
>
>
> On Wed, 4 Jun 2025, 09:03 Tymi via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> I find the move_as example more intuitive and generally "safer". Also my
>> first thought was that std::string(std::move(c)) copied c._value and
>> created a new object out of it, instead of just moving c._value.
>>
>
> You seem to be saying "moving" when you mean "casting to rvalue
> reference", which is not moving.
>
>
> I don't think your std:: expected example works, it didn't have a
> conversion operator. What you want is just std:: move(*exp) or
> *std::move(exp).
>
> And your string example works with just static_cast<std::string&&>(obj).
>
> So I think the existing solutions are fine.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2025-06-04 19:41:59