Why does Qt not support move-only QList?

Question

I want to ask this question again, despite Why do Qt's container classes not allow movable, non-copyable element types? . I have read the following statement by QtCore maintainer Thiago (linked from the linked Stackoverflow question's answer):

Will not be implemented, ever. Copyability is a mandatory requirement due to implicit sharing.

I do not understand this statement: Copyability is a mandatory requirement for implicit sharing, I understand that part. But why is implicit sharing a requirement for a non-copyable QList<T>?

QList already has move-constructors and move-assignment-operators, so assuming that constructing a QList<T> from another temporary QList<T> will not apply implicit sharing, but move the underlying d-pointer, in what cases will implicit sharing arise when only copying/assigning temporary/rvalue QLists around?

Answer 1

All Qt container classes are implicitly shared. This is not something negotiable. How else would you want a signal that emits a QList by value be connected to more than one slot? Without move semantics or without implicit sharing you'd get lots of copies flying around. With move semantics all but the first slot will get an empty (well, unspecified moved from) list. So implicit sharing becomes a necessity in the case of the rest of their API details which contains way too much by value, because why wouldn't they? Everything is implicitly shared anyway.

To summarise: I don't think Qt wants to make exceptions to the implementation of any of their containers such as making a move only list not implicitly shared, whereas any other list would have this implicit sharing. The difference in side effects is just too big.

Also note that at least when reading between the lines, they are moving more towards std containers, although having those appear in the API will take more than anyone'd like...