I would deprecate KFileItemList only when KFileItemVector is a valid replacement (i.e. all the APIs in KIO use KFileItemVector). Deprecating while people are still forced to use it, only leads to a habit of ignoring deprecation signals (since there's no other solution). Introduce Vector, but don't deprecate List just yet.

Based on the comment you made in D10380 it's logical that this commit won't make it as it currently is implemented.
The using line is probably also not the best option if you want to keep the convenience functions, inheriting would be better. But then again, inheriting from an std container gives it's own issues (like no virtual destructor...)

std::vector, for example, is not designed to be inherited and typically should not be inherited (very shaky design), as that will then be prone to this base pointer deletion issue (std::vector deliberately avoids a virtual destructor) in addition to clumsy object slicing issues if your derived class adds any new state.

See: https://softwareengineering.stackexchange.com/questions/284561/when-not-to-use-virtual-destructors

That kinda leaves me wondering how to proceed with this.
Some options i can think of:

1. Do nothing. Leave as is for now and the foreseeable time. No move semantics.
2. Go for the using line (as KFileItemVector) but with a "KFileItemVectorHelper" namespace that contains the current helper function. (or just the KIO:: namespace).
   1. In this case not deprecating the existing API before all other functions that currently use KFileItemList have a KFileItemVector counterpart
   2. Also put this under a compile time define (say -DUSE_KFILEITEMVECTOR) which means the code will be littered with #if statements, but maintains performance as it currently stands. Using this define would disable KFileItemList so that too would be under #if statements.
   3. This also allows for a more graceful transition as not everything has to be implemented at once. Once everything is implemented, add a whole slew of deprecated warnings to all KFileItemList uses.
   4. In KF6 simply remove all #if and end up with only KFileItemVector code paths.
3. Something else?

What's your opinion?

@dfaure What's your preference here?
I do "want" to work on this, no promises though. It could take a very long while ;)

Yep, option 2 sounds like an incremental plan, which is good.