On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote: > Il 01/02/20 12:44, Alberto Mardegan ha scritto: >> On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: >>> About QUniquePointer: what's the point of reinventing std::unique_ptr >>> under a different name? >> >> A Qt-ish API! > > Example?
A data() method :-) >> It's not clear to me what you mean by "alias"; if you mean a subclass, >> then I'd be against it, because there's a (very small indeed) risk that >> in the future the STL adds some methods that might conflict with ours, >> or would not be Qtish enough. > > I mean a type alias: using QUniquePointer = std::unique_ptr; It still bring the risk of the STL adding some weirdly named methods (such as empty()) which we don't want to have in a Qt class. > 1) It's still NIH; Which is not bad per se, in absolute terms. > 2) The probability of future C++standards adding features that won't be > available in the Qt counterpart is 100%; They could be added, and the effort should be minimal (copy the code from STL). > 3) Explain why Qt should raise arbitrary interoperability barriers > literally "for the sake of it"; We can easily provide static fromStdUniquePtr and toStdUniquePtr methods, and there wouldn't be a barrier. > 4) Please justify the teachability efforts involved in explaining all of > the above to Qt users. You can explain it to our users by saying that we want a consistent API, and that while Qt is interoperable with the STL, it can be used without it (and as an alternative to it). Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
