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

[Boudewijn Rempt]

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". So it wasn't a serious C++ library, 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), and everyone doing "proper" C++ looked down on those undereducated morons who were using Qt, instead of "proper" C++. 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!

There is NO useful documentation for STL. 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".

> 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.

> * 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.

> * 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.  

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.

-- 
https://www.valdyas.org | https://www.krita.org