[Development] Proposal: Deprecate QVector in Qt 6

[Edward Welbourne]

Giuseppe said:
>>>> First and foremost, we have a problem of coding guidelines, which
>>>> demand simple pluralization of the entity returned, not "List"
>>>> suffixing:

and conforming with that would fix the *List naming problem, so by all
means let's do that during the lifetime of Qt6, deprecating *List names
in favour of plural replacements.  Too late to do it at th Qt5/Qt6
transition though, so we may as well take our time.

>>>> The major problem in this department has to do with caring that
>>>> something is actually a vector (contiguous in memory, etc.) rather
>>>> than just a sequence implemented "somehow" (... as efficiently as
>>>> possible, this is C++ after all).

If "list" means opaque sequential container and "vector" means a
packaged array, whose contents it makes sense to ask for as .data(),
then that could be a reasonable guidline for when to use which of the
types; use QList to discourage all but iteration of the container, use
QVector to invite grungy low-level access.

On 4/23/20 15:52, Thiago Macieira wrote:
>>> I am also in favor of proposal 2 or 3. I think deprecating either
>>> QList or QVector without any big advantage for the user will just
>>> make porting form Qt5 to Qt6 needlessly harder.
>>>
>>> Even inside Qt we are struggling to keep up with deprecation
>>> warnings (Thanks to Friedemann for fixing these). I am pretty sure
>>> Creator does have the same "problem". Extrapolating that from "just
>>> us" to the broader audience we are hopefully targetting, it looks
>>> like lots of users/applications will be hit by these warnings and it
>>> will mean (lots of?) work for them.

Am 24.04.2020 um 09:22 schrieb Lars Knoll:
>> I do agree that we shouldn’t deprecate neither name, as that would
>> just make moving from 5 to 6 harder. The unification of the classes
>> should help simplify things.
>>
>> But we need to have a consistent message around which name is the
>> preferred one and used in Qt’s own API and documentation. Having a
>> QList in one method and a QVector in the next one would only be
>> confusing to our users. So IMO this thread should mainly be about
>> deciding what the default name for this container is in our
>> documentation and API in Qt 6.

Christian Ehrlicher (24 April 2020 09:33)
> Since you tell everyone since ages that QList should not be used (...)
> and the discrepancy between std::list and QList I don't understand
> what's to be discussed here at all.

Mainly the scale of the change.  Users of Qt are used to the
discrepancy, and a global s/List/Vector/ is seen as too disruptive,
simply because we use QList so pervasively.

If we keep both names, for the one thing, we can gradully make the
transition from one to the other; changing the name of the return-type
of a function won't change the actual API or ABI, so can be done freely,
although changing the *name* of the function will - but, as Giuseppe
points out, the name shouldn't have "List" or "Vector" in it anyway, it
should be a plural.

So if we make one type an alias for the other we don't force any change
on anyone, but we allow ourselves to change which name we use in new
code and convert old code to the extent that we can be bothered.  That
then leaves the question of which name we should use, as Lars says.  I
think consistency with the rest of the C++ universe does make a
compelling argument for QVector.

Fortunately, we don't need to rush; we have the whole lifetime of Qt6 to
make the transition,

	Eddy.