As much as I love getting new features in, I have to agree here. Let's get this into dev as soon as we can, and make sure we have a great story to tell for 5.10.
Cheers, Lars > On 31 Jan 2017, at 12:47, Andy, Nichols <andy.nich...@qt.io> wrote: > > 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.m...@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.m...@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@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
