Date: Thu, 24 Apr 2025 18:11:08 +0300
On 24 Apr 2025 17:59, Ville Voutilainen wrote:
> On Thu, 24 Apr 2025 at 17:48, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
>> The value of the proposal would be standardizing the protocol for
>> creating moved-from objects. This would be useful for generic
>> programming, where the user would be able to create moved-from objects
>> from any library that supports the protocol (whether it is the standard
>> library or not).
>
> How generic is that? If a type doesn't opt in, what happens? Is the
> result ill-formed, or a well-formed break in the attempted generality
> where you just won't get the benefits you thought you get?
It depends on the intention of the developer. If a type doesn't support
this protocol, it indicates that it can't be constructed in a moved-from
state. This might fail to compile (if this support is mandatory for the
generic code), or there may be a different (arguably, less efficient)
code path.
The point is that the "fast" path would be fast and portable, instead of
having to hard-code support for various types.
> On Thu, 24 Apr 2025 at 17:48, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
>> The value of the proposal would be standardizing the protocol for
>> creating moved-from objects. This would be useful for generic
>> programming, where the user would be able to create moved-from objects
>> from any library that supports the protocol (whether it is the standard
>> library or not).
>
> How generic is that? If a type doesn't opt in, what happens? Is the
> result ill-formed, or a well-formed break in the attempted generality
> where you just won't get the benefits you thought you get?
It depends on the intention of the developer. If a type doesn't support
this protocol, it indicates that it can't be constructed in a moved-from
state. This might fail to compile (if this support is mandatory for the
generic code), or there may be a different (arguably, less efficient)
code path.
The point is that the "fast" path would be fast and portable, instead of
having to hard-code support for various types.
Received on 2025-04-24 15:11:11