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

[Knoll Lars]

On 13/10/15 22:46, "Matthew Woehlke" <mwoehlke.floss at gmail.com> wrote:

>On 2015-10-13 15:59, Jake Petroules wrote:
>> On Oct 13, 2015, at 1:46 PM, Marc Mutz wrote:
>>> 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.
>> 
>> 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.

From a conceptual point of view I fully agree with the article. Handling
unicode data is difficult, and that is what’s required to make it as
seamless as possible. But the approach Swift is taking is not trivial or
even 100% unambiguous. Afaik they always work with a certain normalization
form (composed). 

But it poses certain problems as well. With their API, you can always add
a combining character (like an accent) to an existing letter in the
string, but you can never remove it. This creates a certain assymetry that
can in some cases pose problems as well.

>
>While I don't necessarily disagree with that article, I think that the
>points being made are orthogonal to what Marc is proposing.

Yes, to a good degree it’s orthogonal. What both Marc’s proposal and the
article above show is that we should rethink some parts of our unicode
handling with Qt 6. QString is very good in many ways, but it still shows
it’s history as being a vector of utf16 code points.
>
>The idea of QStringView would, I presume, be similar to that of
>std::string_view; namely, to provide an abstraction over a bag of
>"characters" (using that term rather loosely). It does NOT in any way
>relate to doing any sort of operations (besides slicing) on a "string".
>The idea is to be able to inexpensively pass around "text", whether it
>comes from QString, QStringRef, wchar_t*, or what have you, without
>having to perform superfluous memory allocations to convert to One True
>Form (i.e. QString) when the consumer doesn't actually care.
>
>That said... I note that slots probably still need to take QString,
>because a queued call with a QStringView is horribly broken (for reasons
>which I hope are obvious). At least unless the event dispatcher is
>clever enough to promote these to QString in the event.

Yes, as will many other methods. QStringView would IMO mainly something we
can use in places where we use the data in a read-only fashion and where
performance is critical.

Cheers,
Lars