C++ Logo

std-proposals

Advanced search

Re: [std-proposals] move_as

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Wed, 4 Jun 2025 11:19:15 +0100
On Wed, 4 Jun 2025, 10:14 Tymi, <tymi.cpp_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.
>

It seems more verbose and completely unnecessary when you can already
achieve the same thing.

Not being convertible to its result is an intentional design choice for
expected (and for optional) so changing that to enable your new feature
seems like a bad trade off.

> And your string example works with just static_cast<std::string&&>(obj).
>
> And no, static_cast<std::string&&>(obj) does not work.
>

Oh right, your conversion is && qualified. So
static_cast<string&&>(std::move(obj))

I still see no need to introduce a new feature to do this.



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.
>
>
>

Received on 2025-06-04 10:19:32