dfaure added a comment.
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. INLINE COMMENTS > kfileitem.h:550 > + * @deprecated To allow further optimisation opportunities, move semantics > are desired. > + * QList does not support those. Also, QList is generally seen as a bad > container. > + * Therefore deprecating this in favor of @see KFileItemListV2 is resolving > both issues. It's not bad, when sizeof(T) == sizeof(void*), which is the case here. The point about move semantics remains, but that's the only one; let's stick to facts in comments. > kfileitem.h:553 > + * KFileItemListV2 is only a partial replacement though. The convenience > member > + * functions of KFileItemList are gone in it's successor. > */ it's -> its But why not add those convenience methods again, one way or another? Otherwise we'll have massive code duplication. > kfileitem.h:591 > + * > + * List of KFileItems in a std::vecor container. > + * @since 5.44 typo: vector > kfileitem.h:594 > + */ > +using KFileItemListV2 = std::vector<KFileItem>; > + How about naming KFileItemVector instead? Much cleaner name. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D10378 To: markg, dfaure Cc: #frameworks, michaelh, ngraham
