[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Giuseppe D'Angelo]

On 09/06/2019 00:09, Kevin Kofler wrote:
> André Pönitz wrote:
>> I see that pattern, too. But now, instead putting the break between 3) and
>> 4), the whole thing is killed, and everybody downstream has to do 1)-3)
>> again, or put up with what the standard offers.
>>
>> And could prevent overextension by -x'ing the respective change on gerrit.
>> So *that* sounds fixable.
> 
> But why should Qt let itself be crippled by the STL's limitations? Qt
> classes being better than STL classes is a GOOD thing.


Perhaps you forgot to read the part where I said:

> Then, it comes a moment when "upstream" stuff has more and more 
> advantages -- more speed (algorithms), more flexibility (e.g. mutex 
> classes and utilities; shared_ptr<T[]>; etc.), more static analysis 
> tooling, and so on, than the equivalent classes offered in Qt.

So now it's a good time to re-read it.



>>> * We could keep things where they are, supported, thus offering the
>>> easier APIs; but simply reimplement them on top of the "upstream"
>>> equivalents. (Ignore the possible ABI break.)
>>
>> The last one is the most reasonable.
> 
> It is not, because it means Qt can no longer offer features that make it
> better than the STL.
> 
> Instead, the Qt implementation should be kept as is.


Perhaps you forgot to read the part where I said:

> Then, it comes a moment when "upstream" stuff has more and more 
> advantages -- more speed (algorithms), more flexibility (e.g. mutex 
> classes and utilities; shared_ptr<T[]>; etc.), more static analysis 
> tooling, and so on, than the equivalent classes offered in Qt.

So now it's a good time to re-read it.


>>> Long story short, making qSort() call std::sort() might not have kept the
>>> behaviour contract with the user.
>>
>> *shrug*
>>
>> And what if I, as a user, would not care?
>>
>> What about https://valdyas.org/fading/hacking/happy-porting/
> 
> If you break the contract with the user by silently changing the underlying
> implementation incompatibly, you also force the user to do porting (e.g.,
> from qLess to std::less). So the user will care.
> 
> QtAlgorithms should just be undeprecated. I don't care whether std::sort is
> faster. If the version of Qt I tested with was fast enough, then I'm
> perfectly fine with newer versions not being faster, no matter how fast some
> incompatible implementation elsewhere is (and I don't care whether it
> happens to ship with my compiler or not).

I deflect your straw man attack using my amulet of logical fallacies, 
roll 3d4, and summon ad-hominem: this is the kind of reasoning of those 
people asking Henry Ford for faster horses.


A VERY NOT AMUSED,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190610/09a2ab32/attachment.bin>