[Development] QList

[Ville Voutilainen]

Sigh, I failed to reply to the list...

On 18 March 2017 at 21:08, Ville Voutilainen
<ville.voutilainen at gmail.com> wrote:
> On 18 March 2017 at 20:15, Thiago Macieira <thiago.macieira at intel.com> wrote:
>> During Qt 5 development, I began the process of rewriting QList so it suffered
>> less from the problems it suffers, but I ran out of time and it was also an
>> impossible task given the requirement to support C++98 at the time (no
>> <type_traits>). The objective was to make QList a hybrid: a real vector with
>> no overhead for types smaller than 32 bytes, a pointer list otherwise.
>>
>> But as time went by, I don't think that hybrid approach is valid. A vector is
>> simply much better. For Qt 6, I'd like QVector and QList to be the same type
>> -- possibly even interchangeable, so that code that began using QVector in
>> Qt 5 will be able to "return" QList.
>
> Sounds like a plan worth taking a stab at.
>
>>> > In other words, introduce generic code where there wasn't generic code
>>> > before - users writing
>>> > non-generic code calling non-templates that return QLists will need to
>>> > use deduction or a metaprogramming tool.
>>>
>>> No, that is false. You can keep using QList for now everywhere you used it
>>> so far, in non-generic code. Nothing changes for existing types. And for
>>> new types, the compiler will make sure that you don't get away with QList.
>>> We do recommened to use auto to receive QLists to avoid having to port
>>> these code lines manually come Qt 6. I do not consider auto variables
>>> "generic code".
>>
>> I don't agree with the poisoning. See my comment in the QStringView review. I
>
> Nor do I, but if we ever want to do such poisoning, we should poison
> every use of a type,
> including initialization and assignment. We can't realistically
> prevent template instantiations,
> because even C++17 can't do that; Concepts can but those are further
> in the future.