[Development] Feature Freeze Exception: QStringView

[Иван Комиссаров]

Great job!
What about QByteArrayView? Do you plan to use std::string_view instead?
What about toInt/toDouble/etc, toLower/toUpper, right/left/mid (aka
std::string_view::remove_prefix/suffix), find and other QString methods
that doesn't modify the string? Do you plan to add them later or support
only small subset of operations (similar to std::string_view?)
Or maybe i miss some commits?

2017-01-30 22:03 GMT+03:00 Marc Mutz <marc.mutz at kdab.com>:

> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170131/667eb5c9/attachment.html>