<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi,
<br>
<br>
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.
<br>
<br>
Also I'm sad to see that instead of using public mailing lists, you
seem to have discussed this extensively internally.
<br>
<br>
<blockquote type="cite" style="color: #000000;">For sure, it should
only be a choice for newly designed API.
<br>
</blockquote>
How did you come to this conclusion?
<br>
<blockquote type="cite" style="color: #000000;">
<br>
1) Use std::* smart pointers as-is.
<br>
<br>
2) Add Qt-style wrappers around std::* smart pointers and move old
<br>
implementations of Qt smart pointers to the Qt5Compact module.
<br>
<br>
Both options have pros and cons. It would be useful to hear your
<br>
thoughts on it. It’s worth mentioning that some other options,
like
<br>
using Qt smart pointers as-is, were also discussed. They were
found less
<br>
suitable, but feel free to share your opinion if you disagree.
<br>
</blockquote>
<br>
Using a standard class as is the right answer, because:
<br>
<br>
* 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.)
<br>
* There's existing tooling around unique_ptr, and there would be
none for any wrappers.
<br>
* Mixing std code and qt code is easier when they use the same
vocabulary types.
<br>
* The existing smart pointers in qt have less capable API than the
std ones.
<br>
Expecting this to be different the next time seems foolish.
<br>
* unique_ptr is 9 years old. It's behaviour is well understood in
the wider C++ community.
<br>
* There's a feeling that Qt has a NIH problem in the wider C++
community
<br>
<br>
daniel
<br>
</body>
</html>