[Development] The future of smart pointers in Qt API

[André Pönitz]

On Thu, Feb 13, 2020 at 10:01:02AM +0000, Maurice Kalinowski wrote:
> > From: Development <development-bounces at qt-project.org> On Behalf Of
> > André Pönitz Sent: Wednesday, February 12, 2020 8:00 PM To: Allan
> > Sandfeld Jensen <kde at carewolf.com> Cc: development at qt-project.org
> > Subject: Re: [Development] The future of smart pointers in Qt API
> > 
> > On Wed, Feb 12, 2020 at 05:08:33PM +0100, Allan Sandfeld Jensen
> > wrote:
> > > > Allowing _both_ I have not seen actively endorsed by anyone,
> > > > this only makes a messy incosnsistent API.
> > >
> > > I would allow both. It is the only way to remain source
> > > compatible, while making it possible for those that wish to, to
> > > follow the so-called Core guidelines for C++.
> > 
> > I'll rather have a uniform API than to have latest bells and
> > whistles in some random places. 
> 
> I'd like to challenge the categorization of "latest bells and
> whistles" on something which is in the standard for 9 years now.

"Being in the standard" does not really have the kind of positive
connotation for me that some people expect.

std::auto_ptr was in the standard for 12 years in 2010. In fact it was
the *only* "smart" pointer there. And I am rather happy Qt didn't jump
on *that* boat, even though it was highly en vogue with university
dropouts at the time.

> Also considering that Qt 6 is going to have at least the same lifetime
> as Qt 5, 8 years

Is it going to?

I'll owe you few beers and a Döner at Ecki's once Qt 6.7 is out.
But I am rather afraid that the "Let's have a major release each
year and give a damn about compatibility" faction will win before
that.

> this means that you propose to not adapt an item from
> the standard for 17 years?

No, I said that I prefer a uniform API. I propose not to sacrifice
that to partial modernization. 

Amder'