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.