markg added a comment.
Based on the comment you made in https://phabricator.kde.org/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? REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D10378 To: markg, dfaure Cc: #frameworks, michaelh, ngraham
