On 24 Apr 2025 11:17, Jonathan Wakely wrote:
>
> On Thu, 24 Apr 2025, 08:32 Andrey Semashev via Std-Proposals, <std-
> proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
> On 24 Apr 2025 04:14, Jason McKesson via Std-Proposals wrote:
> >
> > Many `std::list` implementations need to have an allocated node to
> > function. So the default constructor creates one. But the move
> > constructor *also* allocates one for the moved-from object, since
> > moved-from objects have to still be valid (this is also why
> > `std::list`'s move constructor is not required to be noexcept). So
> > it's unclear when exactly this would be advantageous.
>
> A moved-from object only needs to be destructible and assignable-to.
>
> Citation needed.
>
> It
> doesn't need to be valid for any other operations. In your std::list
> example, the move assignment/constructor can leave the moved-from object
> without the node, if the std::list's destructor and assignment support
> that state.
>
> 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.

What we have is common sense and what is the absolutely minimum set of
operations that is going to be applied on the object. That would be the
destruction. And since many people also find it useful to be able to
"revive" a moved-from object, I also included assignment.

The other operations are up to the implementer, whether he deems them to
be needed to support and whether they are reasonable to support, given
the cost. Specifically for std::list, if supporting size() etc. on a
moved-from object means that move is no longer noexcept, that would
remove one of the crucial benefits of moving in the first place, and I
would not justify that. Or to put it another way, if std::list takes
this approach, I consider it a poor design.

> I really wish the "moved-from state only needs to support assignment and
> destruction" meme would die. You can use that convention for your own
> types of your want, but please don't tell people it's a general rule.
> It's not.

While not a formal requirement, it is a good general rule to follow,
both as an implementer and a user of a class, to reach an efficient design.