On 24 Apr 2025 17:47, Jason McKesson via Std-Proposals wrote:
> On Thu, Apr 24, 2025 at 7:07 AM Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> On 24 Apr 2025 13:55, Ville Voutilainen wrote:
>>> On Thu, 24 Apr 2025 at 13:48, Andrey Semashev via Std-Proposals
>>> <std-proposals_at_[hidden]> wrote:
>>>>> No, a moved-from std::list also needs to support all operations that
>>>>> have no preconditions, such as size() and empty() and begin() and end().
>>>>
>>>> Well, likewise, citation needed. As far as I know, the standard doesn't
>>>> formally define requirements on the moved-from objects.
>>>
>>> Yes, it does. Your citation is [defns.valid]:
>>>
>>> 〈library〉 value of an object that is not specified except that the
>>> object’s invariants are met and operations on
>>> the object behave as specified for its type
>>> [Example 1 : If an object x of type std::vector<int> is in a valid but
>>> unspecified state, x.empty() can be called
>>> unconditionally, and x.front() can be called only if x.empty() returns
>>> false. — end example]
>>
>> Ok, so the standard library makes extra guarantees about the types it
>> provides. It harms e.g. std::list and I don't agree with this approach,
>> but fine.
>>
>> It doesn't make a general rule about moved-from objects, including not
>> provided by the standard library. And it doesn't invalidate what I said
>> in my post or undermine the usefulness of the proposal.
>
> The standard cannot tell you what to do with your objects. It's valid
> C++ code to make the moved-from state only permit assignment or
> destruction.
>
> The question is what the general prescribed practice is within the C++
> community and what actually gets used in commonly used projects. For
> example, the C++ core guidelines suggest that people should adopt the
> standard's rules for moved-from objects.

Someone sent me a link to Jon Kalb's talk[1] (many thanks!) where he
discusses this issue. He presents an example with a wrapper for a
ViewPortID handle, and I think that example illustrates very well that
this approach is generally not practical. And that is not an entirely
made up example, as I've had similar cases in my practice as well.

All of my types that support move only support destruction and
assignment in the moved-from state. (I think, some of them might not
even support assignment as at some point I was convinced that assignment
already is superfluous.) And it seems I'm not alone. I don't think we
can say that the community is converging on the approach taken by the
standard library.

[1]: https://www.youtube.com/watch?v=FUsQPIoYoRM