[Development] QList for Qt 6

[Mutz, Marc]

On 2019-05-24 09:35, Lars Knoll wrote:
>> On 23 May 2019, at 13:26, Mutz, Marc via Development 
>> <development at qt-project.org> wrote:
[...]
>> You said that QList should vanish from Qt API. So we don't care. We'll 
>> have that switch to make QList _be_ QVector for ese of porting, but as 
>> a template alias. There's your zero-copy conversion :) That leaves 
>> users. And I repeat: I'd leave QList alone (as QArrayList, possibly 
>> with always IndirectLayout), and just have implicit deprecated 
>> conversions between QArrayList and QVector. You shouldn't care about 
>> performance of unported code: It's easy to target both Qt 5 and Qt 6 
>> if you use auto for receiving from Qt API. For sending to Qt API, it's 
>> a bit more tricky. You need to ifdef or live with the implicit 
>> conversion in a Qt 6 build, but it's not something that we should 
>> optimize for. Really. Don’t.
> 
> Sorry, but no. Larger performance regressions that are not really
> visible/cought at compile time can be as large a headache to our users
> as the non stable references to data in the container.

Sorry, you're comparing apples and oranges, iow: a performance issue 
with a correctness issue. You cannot weigh them against each other. We 
need to ensure that user code stays correct _first_, fast _second_. The 
first rule of optimisation: Don't do it. The second rule: Don't do it 
_yet_. Write correct code first, optimize later. You can't turn that 
around. It'd send a catastrophic signal to Qt users.

Here's how I see it: performance problems show up in testing, and are 
easily identified by a profiler, a tool that is available on every 
platform and everyone knows how to use it. Stability of references 
problems are found, if at all, by memory sanitizers, something that much 
less people will be familiar with, and, crucially, might hide in 
less-well tested code.

> I’d argue that it might cause the larger amount of problems as keeping
> references to data in the container is something that’s not used very
> often. But *everybody* will have tons of conversions between QList and
> QVector with your plan for unported code. IMO that’s just as bad.

I disagree. See above. I'd like to add, if I may be so bold, that seeing 
just how widespread unintended detaches are _even in Qt code_, are you 
_actually_ going to tell me that copying a QVector into a QList is going 
to be _noticeable_? It has O(detach) complexity. Yes, in the 5% of code, 
it might get slower (if there wasn't an unintended detach to begin 
with), but as I said: it's easily identified with the simplest of tools: 
a profiler, and in normal testing. The correctness issue may be hiding 
in the 95% that is less well maintained.

Please tell me that I misunderstood you and that you are _not_ going to 
prefer to optimize for speed of _unported_ code, sacrificing correctness 
of the same?

Please?

Thanks,
Marc