[Development] The future of smart pointers in Qt API

[Daniel Teske]

Hi,

I'm confused that there's zero discussion of the work I have done in 
showing how adding unique_ptr apis would look like. Surely, you have 
internally discussed that approach.

Also I'm sad to see that instead of using public mailing lists, you seem 
to have discussed this extensively internally.

> For sure, it should only be a choice for newly designed API.
How did you come to this conclusion?
>
> 1) Use std::*  smart pointers as-is.
>
> 2) Add Qt-style wrappers around std::* smart pointers and move old
> implementations of Qt smart pointers to the Qt5Compact module.
>
> Both options have pros and cons. It would be useful to hear your
> thoughts on it. It’s worth mentioning that some other options, like
> using Qt smart pointers as-is, were also discussed. They were found less
> suitable, but feel free to share your opinion if you disagree.

Using a standard class as is the right answer, because:

* Qt should position itself so that it benefits from innovation 
happening in the standard. Greater interoperability should be a goal. 
(Not just for smart pointers, but in general.)
* There's existing tooling around unique_ptr, and there would be none 
for any wrappers.
* Mixing std code and qt code is easier when they use the same 
vocabulary types.
* The existing smart pointers in qt have less capable API than the std 
ones.
    Expecting this to be different the next time seems foolish.
* unique_ptr is 9 years old. It's behaviour is well understood in the 
wider C++ community.
* There's a feeling that Qt has a NIH problem in the wider C++ community

daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200131/6c6c8f72/attachment.html>