[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Koehne Kai]

I guess it's not by incidence that there's also a std::string_view coming, see e.g.

https://www.youtube.com/watch?v=H9gAaNRoon4

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html

So, is this really the same, except non-templated and for QString (with conversion from/to Qt types)? Or do you have other differences in mind?

Regards

Kai

> -----Original Message-----
> From: development-bounces+kai.koehne=theqtcompany.com at qt-project.org
> [mailto:development-bounces+kai.koehne=theqtcompany.com at qt-project.org]
> On Behalf Of Marc Mutz
> Sent: Tuesday, October 13, 2015 10:47 PM
> To: development at qt-project.org
> Subject: [Development] RFC: Proposal for a semi-radical change in Qt APIs
> taking strings
> 
> Hi,
> 
> After looking quite a bit into the current state of string handling in Qt for my
> QtWS talk last week, I have become frustrated by the state of string handling in
> Qt.
> 
> We have such powerful tools for string handling (QStringRef, QStringBuilder),
> but all APIs outside QString and its immediate surroundings only deal in QString.
> The correct way would be to overload every function taking QString with
> QLatin1String and QStringRef versions, and then, for some other rare cases,
> const QChar *, int size. Let alone std::basic_string<char16_t>.
> 
> I would therefore like to propose to abandon QString for new API (and over time
> phase it out of existing API), and only provide (const QChar*, size_t) as the most
> general form. I would propose to package the two into a class, called
> - you guessed it - QStringView.
> 
> =FAQ=
> 
> Q: Why not just use QStringRef?
> 
> A: QStringRef is tied to QString. E.g. you can't create a QStringRef from a pair of
> QChar*, int. It also is kind of stuck in historic mistakes making it undesireable as
> a cheap-to-pass parameter type.
> 
> Q: What mistakes do you refer to?
> 
> A: The fact that it has copy ctor and assignment operator, so it's not a trivally-
> copyable type and thus cannot efficiently passed by-value. It may also be too
> large for pass-by-value due to the rather useless QString pointer (should have
> been QStringData*, if any). Neither can be fixed before Qt 6.
> 
> Q: Why size_t?
> 
> A: The intent of QStringView (and std::experimental::string_view) is to act as an
> interface between modules written with different compilers and different flags.
> A std::string will never be compatible between compilers or even just different
> flags, but a simple struct {char*, size_t} will always be, by way of it's C
> compatibility.
> 
> So the goal is not just to accept QString, QStringRef, and (QChar*,int) (and
> QVarLengthArray<QChar>!) as input to QStringView, but also
> std::basic_string<char16_t> and std::vector<char16_t>.
> 
> Q: What about the plans to make QString UTF-8-backed?
> 
> A: QStringView-using code will need to be ported just as QString-using code will.
> 
> Q: What future do you have in mind for QStringRef?
> 
> A: None in particular, though I have found a need for an owning QStringRef in
> some places. But I expect Qt 6' QString to be able to provide a restricted view on
> shared data, such that it would subsume QStringRef completely.
> 
> Q: What about QLatin1String?
> 
> A: Once QString is backed by UTF-8, latin-1 ceases to be a special charset. We
> might want something like QUsAsciiString, but it would just be a UTF-8 string, so
> it could be packed into QStringView.
> 
> Q: What about QByteArray, QVector?
> 
> A: I'm unsure about QByteArrayView. It might not pull its weight compared to
> std::(experimental::)string_view, but I also note that we're currently missing a
> QByteArrayRef, so a QBAView might make sense while we wait for the std one
> to become available to us.
> 
> I'm actively opposed to a QArrayView, because I don't think it provides us with
> anything std::(experimental::)array_view doesn't already.
> 
> Q: What about a rope?
> 
> A: A rope is a more complex string that can provide complex views on existing
> data as well as store rules for generating stretches of data (as opposed to the
> data itself).
> 
> A rope is a very complex data structure and would not work as a universal
> interface type. It would be cool if Qt had a rope, but that is outside the scope of
> my proposal.
> 
> Q: What do you mean when you say "abandon QString"?
> 
> A: I mean that functions should not take QStrings as arguments, but
> QStringViews. Then users can transparently pass QString, QStringRef and any of
> a number of other "string" types without overloading the function on each of
> them.
> 
> I do not mean to abandon QString, the class. Only QString, the interface type.
> 
> Q: What API should QStringView have?
> 
> A: Since it's mainly an interface type, it should have implicit conversions from all
> kinds of "string" types, but explicit conversion _to_ those string types. It should
> carry all the API from QString that can be implemented on just a (QChar*, size_t)
> (e.g. trimmed(), left(), mid(), section(), split(), but not append(), replace() (except
> maybe the (QChar,QChar) overload.
> Corresponding QString/Ref API could (eventually) just forward to the
> QStringView one.
> 
> Thanks, now fire away,
> 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 Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development