[Development] QtCS 2017 QtCore sessions

[Marc Mutz]

On 2017-12-02 18:54, Ville Voutilainen wrote:
> On 2 December 2017 at 18:48, Marc Mutz <marc.mutz at 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