On Friday 15 January 2016 03:58:12 Kevin Kofler wrote: > Иван Комиссаров wrote: > > Still, what about policy not to use std:: classes in Qt API? > > So why not just add a QOptional that works the same as std::optional?
a) because we can't (we don't yet require the necessary language features) b) because once introduced, people will add all kinds of Qt-specific stuff to it, making it impossible to replace it with std::optional down the road. And since it will be good enough for the low demands of Qt development, it will no longer see development and fall behind the state of the art. <rant> Consider QVector: it has been Qt-ifed by both adding (technically) useless duplicate Qt-ish API, CoW, and a Qt-specific type classification scheme plus corresponding optimisations that make it very hard to argue for std::vector use instead. The Qt community had two decades where they could have influenced the direction std::vector would take so it could allow the same optimisations that QVector has, but the time and energy was instead put into re-writing the containers for every major release (yes, for Qt 5, too, and Thiago's Qt 6 QVector again looks much different from the Qt 5 one). The CoW makes QVector slow and increase code size, leads to hidden detaches that not even Qt experts regularly avoid in their daily work, and doesn't even work properly because you can take iterators into a QVector and, after copying the vector, change both copies through the iterator into the first. That is a conscious trade-off because making the container unsharable, as it must become once it hands out iterators, would make CoW fail to take effect _all the time_. But it leads to careless copying of QVectors that also doesn't really help with porting to std::vector. All the while - and I don't believe I'm saying this - std::vector *blazes the trail* with move semantics, emplace_back and stateful allocators (making QVarLengthArray all but useless). Does QVector use move semantics? No. Does QVector have emplace_back? No. Does QVector have an allocator, even one that, citing Alexandrescu, actually deals with allocation? No. Does QVector, even with Q_PRIMITIVE_TYPE payloads, expand to less code as std::vector? No: https://codereview.qt-project.org/145587 (comment from 01-14 11:21). Does QVector have a debug mode comparable to that of std::vector implementations? Nope. Or: The only reason I ever used std::list was to use its splice() feature. Does QLinkedList have splice()? No, of course not. Because it _cannot_ (it's CoWed: how do you take ownership of nodes if the they are shared? By copying all other nodes in a detach()?). This is why we need to stop duplicating std API. It's not Qt's core competency to meddle with things we only have a half-interest in. It's fun to write QOptional. Until it isn't anymore. And then the (Qt) world needs to live with the poor-man's std::optional for the next few decades. </rant> Please, no. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
