Hi,

Il 22/03/26 11:20, Ell ha scritto:

> But the more realistic case is the other way around: types that are move
> constructible but not move assignable. They can't be shifted via
> assignment, but can be shifted via relocation. I'm pretty sure you're
> not proposing that implementations are required to use relocation in
> this case (not with this paper, anyway; not necessarily a bad idea in
> general), but in several places it says that the requirements of erase()
> become "Cpp17MoveAssignable*or* Cpp17MoveInsertable", which suggests
> that implementations*are* required to support that.

I should probably draft some wording to make it clear... I'm not sure if
I should push for this right away, or if that's aiming "too high"?

But this is definitely going in the direction I'm proposing. If I get
there, I would probably add a "Cpp17Relocatable" requirement and, for
erase, require either that or Cpp17MoveAssignable. (A similar discussion
applies to emplace / insert.)

This is basically laying the foundational work not only to support
relocate-only types in these containers, if/when we get there, as well
as unlocking the trivial relocation optimizations.

Thank you for your feedback,
--
Giuseppe D'Angelo