[Development] Feature Freeze Exception: QStringView

Tue Jan 31 12:47:03 CET 2017

While QStringView looks like a nice addition to Qt, I don’t think we should risk delaying the next release over it.  It is bad enough there is always a rush to cram things in the week leading up to the release and even worse when we start talking about extensions.  If we are going to have time based releases we need to follow the rules, and accept that there is always another release.  It’s much better to integrate early and have time to work out the kinks, rather than integrate a feature at the last second.

> On 31 Jan 2017, at 12:07, Marc Mutz <marc.mutz at kdab.com> wrote:
> 
> Hi Lars,
> 
> On Tuesday 31 January 2017 10:08:35 Lars, Knoll wrote:
> [...]
>>> So, in order to give the maintainers more time for review, I'd like to
>>> ask for a feature freeze extension for QStringView until end of next
>>> week, plus a few days to deal with maintainer review comments.
>> 
>> I understand that you want to have the patch series finally merged.
>> Actually I do as well, I believe that QStringView is the right approach
>> moving forward.
>> 
>> But I do wonder about the approach here. The series has been around pretty
>> much unchanged for quite some time now without anybody working on it. You
>> had lots of time since summer to get this into shape an merged. Now, a
>> week before the feature freeze and suddenly this absolutely has to go in?
> 
> I have been sxcheduled to work on this in January, but was out with sick child 
> and then myself afterwards for almost two weeks. That's why it's late.
> 
> Then again, as you say, the main patch has been around for the better part of 
> a year, and the basic idea has been around since the beginning.
> 
>>> Why should it be granted? Because QStringView is by far the biggest
>>> revolution in Qt since 5.0, all the while integrating naturally and
>>> step-by-step into existing code, _tremendously_ simplifying it along the
>>> way (cf. the commits that start to make use of QStringView:
>>> https://codereview.qt-
>>> project.org/183864 https://codereview.qt-project.org/183925), esp. where,
>>> in private API, we can already remove the other overloads.
>> 
>> I agree, that the series cleans things up and is a great improvement. But
>> the biggest revolution since 5.0? It's an API addition that brings
>> performance optimisations in Qt's string handling.
> 
> No, this is not at all about performance. It's mostly about stream-lining the 
> API, and adding flexibility:
> 
> 1. Traditionally, a lot of stuff has been taking QString, and QString only. If
>   you're lucky, you get (QChar*, int) on top, so you can use an automatic
>   buffer to hold the string data, with all the ugliness at the
>   call site that entails. QStringView takes all that pain and hides it
>   (see https://codereview.qt-
> project.org/#/c/183925/2/src/corelib/tools/qtimezoneprivate_win.cpp,unified).
>   It also allows for clearer interfaces, because instead of a QString and an
>   int, you can just pass a QStringView, since creating a sub-view suddenly
>   costs nothing:
> 
> 2. QStringView gives the caller the choice of container for string data. This
>   makes Qt much more interoperable with 3rd-party libraries. QStringView will
>   make QStringLiteral all but obsolete, since you can now just pass u"string"
>   or, on Windows, L"string" to any QStringView-taking function. We can
>   trivially define a QStringViewLiteral that uses one of the other, depending
>   on platform. I backed that feature out, though, since I fist need to verify
>   that we support no compilers anymore that would fall back to fromUtf8() for
>   QStringLiteral.
> 
> 3. And yes, performance. Where today we have to return QString, even where we
>   know a maximum size, and even where we don't:  It will allow
>   QLocale::toString() to return something equivalent to char16_t[N], e.g.
>   std::array, in order to not allocate memory just to format numbers,
>   something that has so far eluded any practical solution. For internal
>   functions that return temporary QStrings, we can switch to QVarLengthArray,
>   and avoid heap allocations in common cases.
> 
> The last such fundamental change to QtBase was the possibility to connect 
> signals to lambdas. Believe me, QStringView has the same caliber.
> 
>> What would we really loose if we worked towards getting this into the dev
>> branch in the next few weeks? We don't exactly have hundreds of
>> users/customers who can't live without it. And pushing it into dev would
>> give you lots of time to make sure we make best possible use of the class
>> throughout all of Qt for 5.10.
> 
> I have found that even with just relational operators, conversions, and 
> iterators (ie. just the Long-live commit in the series), maybe 
> QString::append() and QStirngBuilder integration, you can already do a lot of 
> stuff. For us, getting QStringView into dev next week means one week of delay, 
> but for our users, it means half a year delay. Qt is desperately in need of 
> better integration with std C++, and QStringView is hand-down the largest such 
> contribution. Not having it means people will continue to spend^Wwaste time 
> porting stuff to QStringRef, which will later be replaced by QStringView. 
> Don#t get me wrong, I love the work Anton and others have done in the area. I 
> now just need to grep for QStringRef to find code to port to QStringView, but 
> the real value of QStringView lies in where there was no QStringRef-overload 
> in the first place, e.g. QColor: https://codereview.qt-project.org/184038
> 
> In the end, it's your call, of course.
> 
> I personally don't care whether it goes into 5.9 or 5.10, but for our users 
> and for other contributors, I hope that it makes it into 5.9, since, judging 
> from 5.8, a lot of internal performance improvements come into stable 
> branches, and we really don't need more QStringRef uses in Qt. esp. in public 
> API, where we need to carry it all the way to Qt 6.
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development