[Interest] The willy-nilly deletion of convenience, methods

Matthew Woehlke mwoehlke.floss at gmail.com
Tue Mar 23 17:02:04 CET 2021


On 23/03/2021 11.44, Volker Hilsheimer wrote:
> I wished I had seen the level of energy y’all are putting right now
> into this email thread over the last two years when we discussed
> where to go with Qt 6, and when the work actually happened.
IIRC, I complained plenty about QList at the time. I wouldn't be 
surprised if I complained about QHash also.

One of the reasons I don't try to contribute more than I do is because, 
when I *have* contributed patches, it hasn't accomplished anything.

>> So far, all I've seen is "C++ also deprecates stuff". You haven't
>> shown that the deprecations are actually *harmful* to the C++
>> community. >
> Personally, I’m siding with those folks in the committee that
> believe that not changing things (ref ABI discussion) is more harmful
> than if we’d be able to fix now and again what is objectively
> broken.

Likewise.

I've even said before that it might be beneficial if C++ could more 
aggressively deprecate bad stuff, even mentioning Qt as an example to 
follow.

Not all deprecations are bad. However, I still maintain that *some* of 
the Qt 6 changes are problematic. Also, TBH, I think the real issue is 
less that Qt 6 made changes, and more that Qt 5 support got pulled well 
before Qt 6 is viable for most folks. That didn't happen with Qt 4 → 5.

I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff that 
was immediately removed in Qt 5.0, although I may be wrong about that.

> I personally wonder why people that never want to change what they 
> built last year want to develop software development. Isn’t that
> what makes building stuff out of bits and ideas so much more
> interesting than building stuff out of sticks and stones?

Is this really so surprising? People want to spend their time making 
*their* software better, not chasing an ever-shifting foundation on 
which their software is *built*.

Time spent adapting to library changes, especially changes seen as 
unnecessary or actively harmful, is time *not* spent developing new and 
exciting features, or even squashing existing bugs.

-- 
Matthew


More information about the Interest mailing list