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

[Volker Hilsheimer]

> On 23 Mar 2021, at 15:49, Matthew Woehlke <mwoehlke.floss at gmail.com> wrote:
> 
> On 23/03/2021 10.36, Benjamen Meyer via Interest wrote:
>> On 3/23/21 10:09 AM, Matthew Woehlke wrote:
>>> Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any
>>> change, not just on a mailing list, but in person. Anyone can, in theory
>>> (in practice, depending on where you live, there may be a non-trivial
>>> membership fee required) *vote* against a change. We, as the committee,
>>> generally try to be considerate of the community when making changes,
>>> and there is quite a lot of emphasis on not breaking existing code, even
>>> as far back as C++98.
>> How many C++ devs are on those?
> 
> Hundreds, which is probably more than the number of people making decisions for Qt.
> 
>> Likely only those whose companies are paying them to be, and a few
>> that got there via academics (I've personally known and worked with
>> one person; outside of the folks I've seen here on the Qt lists.)
> 
> Even so, that's a lower bar than "you must be an employee of TQtC" (and even that is probably not sufficient). The bar also happens to be much lower right now due to COVID, since there are no in-person meetings happening.


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. Code and header reviews are all done in public, and it’s usually the same small handful of people that put an effort into those. And I’m extremely grateful to those people who do, and there were tons of occasion during the Qt 6 development where someone outside The Qt Company criticised a change, perhaps even -2’ed it, and made things better by putting their git (or at least gerrit) credentials next to their opinion.


Of course, The Qt Company paying several dozens of software engineers to work full-time on the various parts of Qt (the framework, the tools, the CI system) has a big momentum, and yes we have colleagues that can approve changes quickly. But the deprecations that seem to cause the most controversy right now - like removing toContainer helpers - were not implemented by a TQtC employee, and neither is the maintainer of the Qt Core module on TQtC payroll.

As the one who killed QDesktopWidget and a bunch of other, previously deprecated APIs for Qt 6 - I personally prefer to not have my code compile anymore if it wouldn't work as it needs to anyway. That’s better than code that builds, but doesn’t work, or doesn’t scale, or prevents long-term improvements. Yes, that’s to some degree my personal opinion, but it’s evidently also the general principle of The Qt Project (even if not written down in some quip or manifest) and it’s also the opinion of the folks in the Qt Project that +2’ed my changes.


Maybe ideally nobody would have to change anything ever, and we only get to use new things that work perfectly with the old stuff all the time. But knowing about what it costs to build software this way, we have decided that this is not how we are building Qt. This is not exactly a surprise, after 25 years and 6 major Qt releases, all of which have removed old APIs.


> In any case, you've made an unsubstantiated allegation that the committee does not care about C++ users.


And you have made the unsubstantiated claim that people outside of The Qt Company have no influence on the direction The Qt Project is (technically) taking - yes, the licensing shenanigans excluded.


> Please provide evidence to back that up. 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 on anything like the scale to which Qt's recent changes have been harmful.


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.


> Deprecations, even in Qt, aren't always bad. Some recent Qt deprecations, however, have caused major pain. Now you are apparently claiming that C++ is "just as bad", but I have yet to see that claim substantiated.


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?


Volker