[Development] Feature Freeze Exception: QStringView

[Marc Mutz]

Hi,

QStringView is ready to be merged, but the maintainer has asked for another 
week before he can properly review the class.

In case you don't remember, here's the discussion thread from 2015: 
http://lists.qt-project.org/pipermail/development/2015-October/023358.html

Here's the evolving patch series:
https://codereview.qt-
project.org/#/q/status:open+project:qt/qtbase+topic:qstringview,n,z

I feel the patch addresses all concerns raised in the discussion:

1. size_type: we agreed on on ssize_t equivalent to strike a balance between
   the Qt preference of 32-bit signed types over the STL preference for 64-bit
   unsigned types.
2. Do this in Qt vs. do this in QtCreator. I believe that a QStringView
   without deeply-routed support in QString would be a still-born. We also
   don't have time come Qt 6 to port all of Qt to a QStringView developed
   elsewhere. The current patches just scratch the surface. Everywhere
   QStringRef is currently used, QStringView can be used. And a lot of places
   that traditionally only took QString should take QStringView, too, e.g.
   QFile::encodeName(). So I added it to Qt.
3. Keeping existing QString overloads for implicit sharing.
   The patch does not remove anything. It will, as it progresses, implement
   QT_STRINGVIEW_LEVELs 2 and 3 which remove existing QString and QStringRef
   overloads (2: only where the function read from the string, 3: also where
   it stores the string), so that at some later point in time we can just flip
   a preprocessor switch and compare executable size and execution speed of
   both sets of overloads, everything else being equal.

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.

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.

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