Hi, as it seems we will not be able to reach a broader consent on the usage of std:: smart pointers in our current API because of several reasons:
* the resulting API might be inconsistent * slow adaptation in user code after the massive API change * current legacy code base is to huge to adapt in the Qt6 time frame * unpredictable behavior changes and limited possibility to test the introduced API's * no well defined process on how to vote on the decision to move away current API's * I might have missed some other obvious points here. Still this does not mean we should move on without rethinking the possibility of using std:: smart pointers in newly created API's; either in new modules and or to a given extent in existing ones. Thus I would like to propose the adaptation of our coding style and coding conventions to explicitly _allow_ the use of std:: smart pointers where we see fit. Hopefully in the long run this would also make it easier to transition current API's from owning raw pointers to std:: smart pointers. Does this sound like a more reasonable approach? -- Karsten -----Original Message----- From: Development <development-boun...@qt-project.org> On Behalf Of Maurice Kalinowski Sent: Donnerstag, 13. Februar 2020 11:01 Uhr To: André Pönitz <apoen...@t-online.de>; Allan Sandfeld Jensen <k...@carewolf.com> Cc: development@qt-project.org Subject: Re: [Development] The future of smart pointers in Qt API > 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. Also considering that Qt 6 is going to have at least the same lifetime as Qt 5, 8 years, this means that you propose to not adapt an item from the standard for 17 years? What about new modules? There has been the proposal to at least enable them for those? Furthermore, we should not hinder/block external projects to adapting. As long as this is supported, that could be some middle-ground. Maurice _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
