Date: Wed, 4 Jun 2025 12:32:01 +0100
On Wed, 4 Jun 2025, 11:56 Tymi, <tymi.cpp_at_[hidden]> wrote:
> The U& is a typo, U&& would be the correct one. Wrote that one on the fly
>
Then it's broken for lvalues, you need to use remove_reference_t<U>&& in
the body
Please actually implement this and test it properly before proposing it
here, where lots of people spend time on it.
> Tymi.
>
> On Wed, 4 Jun 2025, 12:54 Tymi, <tymi.cpp_at_[hidden]> wrote:
>
>> Same reason why std::move exists
>> Why do we have std::move? Why not just use static_cast<T&&>(value)?
>>
>> Tymi.
>>
>> On Wed, 4 Jun 2025, 12:19 Jonathan Wakely, <cxx_at_[hidden]> wrote:
>>
>>>
>>>
>>> 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.
>>>>
>>>>
>>>>
> The U& is a typo, U&& would be the correct one. Wrote that one on the fly
>
Then it's broken for lvalues, you need to use remove_reference_t<U>&& in
the body
Please actually implement this and test it properly before proposing it
here, where lots of people spend time on it.
> Tymi.
>
> On Wed, 4 Jun 2025, 12:54 Tymi, <tymi.cpp_at_[hidden]> wrote:
>
>> Same reason why std::move exists
>> Why do we have std::move? Why not just use static_cast<T&&>(value)?
>>
>> Tymi.
>>
>> On Wed, 4 Jun 2025, 12:19 Jonathan Wakely, <cxx_at_[hidden]> wrote:
>>
>>>
>>>
>>> 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 11:32:17