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

[André Pönitz]

On Tue, Jun 04, 2019 at 09:58:18PM -0700, Thiago Macieira wrote:
> On Tuesday, 4 June 2019 12:57:36 PDT Mutz, Marc via Development wrote:
> > You talk about a particular incarnation of stdlibs, I was talking about
> > the general case. Yes, in the case you describe, and _if_ libc++ is
> > configured to be compatible (which in the past you have complained is not
> > done correctly), then it may work. But take STLport vs. Rougewave on
> > older SunCC. Or Dinkumware vs. GCC on QNX.
> 
> Yes, I've complained that most distros can't seem to compile them to be
> compatible correctly. But that's not Qt's problem that one (or most) of
> them fail to do their job properly.

It's not "Qt's problem" per se, but it's becoming the problem of Qt _users_
once Qt is not shielding them anymore.

And once that happens, Qt's utility for those user decreases, and *that* in
turn *might* become Qt's problem.

I am not saying it *will*, but it's a thing that needs to be taken into
consideration.

And so far all real world data points I have is that the ongoing deprecations
are a major pain, continously eating into *my* time, and none of the alledged
advantages *including run time performance* ever came to state where it was
noticable, let alone obvious, in my daytime work, which incidentally happens
to a large degree within Qt Project code.

> In a properly configured environment, there could be users who want to perform 
> this mixing.
> 
> But no, I don't think we should use that as an argument for avoiding Standard 
> Library API in our classes.

Neither me, actually. But it should also not serve as an excuse to run a
"quixotic crusade to de-Qt Qt" [1]

> For example, we should use std::unique_ptr.

... "when it makes sense". Not just because of IFONP.

Andre'

[1] See https://valdyas.org/fading/hacking/happy-porting/ for a definition.