[Development] Proposal: Deprecate QVector in Qt 6

André Pönitz apoenitz at t-online.de
Thu Apr 23 17:52:53 CEST 2020


On Thu, Apr 23, 2020 at 12:25:33PM +0000, Vitaly Fanaskov wrote:
>    I think we should completely remove QList in Qt6. It was planned
>    before, as far as I remember. The main reason is to be consistent with
>    STL wording and do not violate POLA too much.
> 
>    I read the entire discussion, and I'd like to say this one more time:
>    we don't have to fight the consequences. Better to eliminate a cause.
>    There always will be a functionality to deprecate. There always will be
>    controversial APIs, that, for example, contain a hard-coded type
>    information in the name (e.g. "windowList()" instead of "windows()").
>    Why not think about it instead? Today it QVector vs. QList, tomorrow
>    something else...
> 
>    We can at least shorten release cycle to one year.

One year for a major Qt release and then break API?

How many people have you seen that use Qt as a means to get *their*
problem solved, and how many of them prefered adapting their code to
Qt API changes over working on there own code?

How often do you think we can play this game until people look for
something they consider more stable?

>    Provide clang-based tools to (semi-)automatically port users' code
>    bases to a new version of Qt.
>
>    These tools might either fix a code or at
>    least add a comment in potentially problematic places where a user
>    should correct the code. A developer who changes API should also
>    implement a rule for these tools.

This magic tool comes up over and over again, still no-one "just did it".
Maybe because it's not *that* trivial after all, maybe because doing that
actual porting ends up in real work, which is  much less fun than just
deciding that something needs to be changed, maybe something else.

Really: All this talk "this is bad, should be done differently, and
then it is better" would be much easier to believe if they were accompanied
by patches that implements that change for all of Qt. Or all of KDE.

Andre'


More information about the Development mailing list