On Thu, Feb 13, 2020 at 10:01:02AM +0000, Maurice Kalinowski wrote: > > From: Development <development-boun...@qt-project.org> On Behalf Of > > André Pönitz Sent: Wednesday, February 12, 2020 8:00 PM To: Allan > > Sandfeld Jensen <k...@carewolf.com> Cc: development@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' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
