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

[Giuseppe D'Angelo]

Hi,

On 08/06/2019 19:17, Boudewijn Rempt via Development wrote:
> I kept out of this for the longest time, especially because people have been quoting my blog post, but I give up now.
> 
> On zaterdag 8 juni 2019 18:14:36 CEST Giuseppe D'Angelo via Development wrote:
> 
>>
>> 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.
> 
> Qt's problem has been that it was started as "let's make c++ accessible to "java coding drones". 

Please don't say "coding drones".

> So it wasn't a serious C++ library, 

[citation needed]

> so nobody using Qt cared about C++ (I still don't care about C++, I don't do C++ because it's awesome, but because I inherited a codebase that uses it), 

I still consider C++ a _tool_ and not necessarily an _end_. Surely 
that's also what lots of our customers see out of it.

> and everyone doing "proper" C++ looked down on those undereducated morons who were using Qt, instead of "proper" C++. 

Do not use this language. (And, [citation needed]).


> And then Qt became one of the most-used C++ platforms. Mostly because Windows developers were even more often hit by the fire-and-motion tactics of Microsoft, and because of the web and other languages getting useful and all of that. So now C++ people have noticed Qt, and Qt people have noticed the C++ people, and the reaction is... Let's do more of the stupid stuff that's been in STL. 



> Let's write documentation that's only accessible to CS majors, no, let's do better, let's have documentation only accessible to CS professors!

[citation needed]

> 
> There is NO useful documentation for STL. 

Is this a comprehensive review of ALL the information ever published 
about the Standard Library?


> Just look at how ivory-tower the documentation for std::unique_pointer is on cppreference. Good documentation tells me "what does this, why should I care, when should I use it, how should I use it". The cppreference documentation tells me "this is the right vocubulary to talk about this topic, and there are these weird cornercases".

Straw man. cppreference is to be an API reference for experts, not a 
tutorial. From their FAQs:

> The primary objective is to have a good specification of C and C++. 

Tutorials about smart pointers are elsewhere.


> 
>> In other words, the advantages of keeping the Qt equivalents start to be
>> (seriously) questioned. We're therefore left with the question of what
>> to do with these equivalents.
> 
> Like always, like I'm always being told, but dammit, we're trying to do that, only we're not getting through gerrit, much, you should have upstreamed it. The stl should have become Qt-like, not Qt stl-like.

I cannot parse the first sentence at all.


>> * We could play the catch-up game, but that requires a development
>> investment that is simply not there any more, and is even questionable
>> (is it the job of people developing Qt to rewrite algorithms widely
>> available elsewhere?).
> 
> Qt never had the manpower to maintain its stuff, not even in the Nokia days.

So?


>> * We could just deprecate and tell people to migrate away. That's kind
>> of the whole point of this thread, and comes with all the annoyances,
>> and people reimplementing them downstream because they still want the
>> convenience of a qSort(vector) over std::sort(vector.begin(), vector.end()).
> 
> It's not about annoyances. It's about not having to rewrite code, spend time, without getting any tangible benefit in the hands of my users. The kind of memory savings Marc Mutz keeps hammering on about are totally, utterly, completely, devastatingly irrelevant for me. Qt churn doesn't get me any new users, or makes any of my current users happier than they were already.

I reject this claim. It's completely short sighted. In this design, any 
sort of internal maintenance one does on a piece of software does not 
bring "tangible benefits" to the users.


> If you write a library, you only have one task: make sure your users can deliver functionality to their users faster, better, more reliably than if they would use another library. Making your users spend time porting, is wasting your users time and money.

No. There is, for instance, also the task of maintaining said library.
  My 2 c,

-- 
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/e668d023/attachment.bin>