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

[Matthew Woehlke]

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.

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

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.

-- 
Matthew