[Development] The future of smart pointers in Qt API

[Vitaly Fanaskov]

>> We should also move Qt smart pointers to Qt5Compat module. The destiny
>> of QPointer is not well defined so far.
> This was not part of the research and should probably discussed separately.
I agree. But if we decide using standard smart pointers, why should we 
keep Qt smart pointers as a part of Qt6? It would be a duplication in 
this case. I thought that it is just a logical consequence.

On 2/12/20 11:57 AM, Karsten Heimrich wrote:
> Many thanks Vitaly for taking the time and effort to get the discussion going.
>
> -----Original Message-----
>> From: Development<development-bounces at qt-project.org> On Behalf Of Vitaly Fanaskov
>> Sent: Dienstag, 11. Februar 2020 16:15 Uhr
>> To: development @qt-project.org
>> Subject: Re: [Development] The future of smart pointers in Qt API
>>
>> I want to summarize intermediate results of the discussion and return it back to the track.
>>
>>
>> Subject: using smart pointers in the API.
>> Good idea.Better to use than not because of automatic lifetime
>> management, explicit ownership semantics, and code base maintainability
>> is simpler.However, it doesn’t mean that this is a mandatory choice for
>> all API, just a recommended way so far.
> If the outcome of this discussion is to not use/ introduce smarter pointers in our public API's right now, it's still worth considering an update to our API design principles for new modules.
>
>> Subject: standard smart pointers vs. Qtish wrappers.
>> In general, people want to use standard smart pointers.There are a few
>> main reasons: std-things are already in Qt API, this is a part of C++
>> language standard, it requires almost no maintainability, people outside
>> of Qt ecosystem most likely get used to standard smart pointers for nine
>> years.
> I can only second that, we should not invent our own wrappers around std:: smart pointers just for the shake of typography.
>
>> We should also move Qt smart pointers to Qt5Compat module. The destiny
>> of QPointer is not well defined so far.
> This was not part of the research and should probably discussed separately.
>
>> Subject: raw pointers for passing mandatory parameters vs. using
>> references.
>> Allow both approaches, recommend using references (and/or smart
>> pointers) when acceptable. Not too many arguments collected here, just
>> try to make Qt API more modern.
> I think because most of the discussion has been centered around the use of smart pointers in widgets/layouts/ui centric stuff, we might have lost view on the way more generic uses of raw pointers in our API. Some of our classes return raw pointers (QModbusReply and things like that come to my mind), where ownership is not clear/ now well documented/ not documented at all; and I can clearly see said API's benefit of the introduction of smart pointers.
>
>> There are a few irrelevant discussions. Start a new thread if you want
>> to continue discussing them, please.
>>
>>
>> Irrelevant subject: smart pointers vs.parent-child lifetime management
>> model.
>> It’s too fragile to touch in Qt6.Adding smart pointers around is
>> questionable solution, it’s unclear whether it worth doing or not.
>> Having two different but coupled mechanisms for lifetime management is
>> not such a good idea.
> True. We might not be able to address it for Qt6, but I think it's still worth to keep in mind and re-question the current approach. Daniels patch seems to be the best starting point so far.
>
> -- Karsten

-- 
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team