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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
