On 2017-12-02 18:54, Ville Voutilainen wrote:
On 2 December 2017 at 18:48, Marc Mutz <marc.m...@kdab.com> wrote:
If that analyis were true, you'd need to explain why it is, then, that
the
Qt containers now have more or less the same API as std ones, when in
Qt 1
they were very different. And why I keep needing to fight off
QOptional.
..
And, c'mon, std::optional's API is just not going to be topped by
QOptional.
What should they do? snake_case vs. camelCase? That's what we need to
invest
several man-days of development work in, to rename the functions and
stick a
Q in front of the class name?
There's one thing that a QOptional could do that std::optional can't:
be available for all Qt users
in a time span of a couple of months.
And I'm not against it. I, personally, did that for
qAsConst/std::as_const. And we had qtypetraits.h, too. But if we copy
std functionality, it must be and stay 100% behaviour-compatible with
the corresponding std type. As a consequence, it was trivial to move
away from qtypetraits.h, and it will be trivial to move from qAsConst to
std::as_const. The problem comes in when you add functionality to the Qt
copy that is not in the std equivalent. As such, I'm asking, like for
bug-fixes, to merge the feature upstream first, then implement it in Qt
when it becomes apparent that upstream will adopt the change.
And as with qtypetraits.h, we should _copy_ a 3rd-party component
instead of implementing it ourselves.
Another excellent example of correctly working with upstream is
QRegularExpression. The author first added UTF-16 support to libpcre,
and _then_ added QRegularExpression on top, instead of, like it was done
for QRegExp, implement the automaton himself.
The QRegularExpression API is also closer to std::regex than QRegExp.
The latter, despite originating in Qt, does not really have a more
convenient API than std::regex.
But if a QOptional is added with a nullable-Qt-types optimisation
already built-in, or QStringView(Char*) is missing constexpr when
std::string_view(char*) does not, then this is a functional fork that I
consider unacceptable.
So, to summarize my position:
1. It's ok for Qt to add copies of std functionality. It may even have a
Qt-ish API (QClass::camelCase()).
2. But it must never, ever, add functionality that the std equivalent
does not have.
3. Unless Qt is leap-frogging in front of the std with this (like
Unicode support in QString), functionally. Performance does not count,
as that should be fixed upstream.
4. Even so, Qt-as-a-project should actively participate in upstreams
(incl., but not limited to, the C++ standard) to get added functionality
upstreamed.
An example of (4) would be for TQC to participate in the text_view
discussion. Another is Olivier's co-operation with Herb and Andrew on
exploring porting Qt's metaobject system to C++ metaclasses.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
