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

[Jake Petroules]

> On Oct 13, 2015, at 1:46 PM, Marc Mutz <marc.mutz at kdab.com> wrote:
> 
> 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


In general this sounds like a dangerous idea because it carries over all the old API concepts (i.e. (QChar *, size_t) is an extremely broken abstraction). You need to read and truly comprehend https://developer.apple.com/swift/blog/?id=30 before suggesting any changes to string-related APIs for the next major version of Qt, because if anything, THAT is what it should look like. Anything but that is a near-useless wrapper around binary data, not a true string class.
-- 
Jake Petroules - jake.petroules at petroules.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151013/97cb3506/attachment.html>