[Development] QAnyStringView

[André Somers]

<warning: bike shedding ahead>

On 29-06-20 09:20, Edward Welbourne wrote:
>>> BTW, any chance we can bait-and-switch, renaming QStringView to
>>> QUtf16StringView and rename QAnyStringView into the newly liberated name?
> Philippe (25 June 2020 08:40) asked:
>> When we deal with strings, the "Uff" affix is unecessarily verbose.
Nice illustration of the problem with Utf as a prefix right there...
>>
>> I mean,
>>
>> QStringView16
>>
>> is understandable and more friendly/readable than
>>
>> QUtf16StringView
> Notice that we want to distinguish QLatin1String from QUtf8StringView;
> although both are 8-bit encodings, Latin-1 and UTF-8 give different
> meaning to some 8-bit tokens.
>
> Likewise, the point of saying QUtf16StringView would be to make clear
> that the encoding is UTF-16 (a.k.a. UCS-2); whereas QStringView16 only
> says it uses 16-bit units to store its contents, it doesn't say what
> semantics it gives to those 16-bit units.  (Not that I'm aware of any
> other 16-bit encodings, as it happens.)  So the point is to indicate the
> encoding, not just the size.

Yes, yes. That's all correct.

But since these classes are used *a lot*, it is IMO also important to 
pay attention not only to technical accuracy but also to how easy they 
are on the eyes. I find QUtf8String* and QUtf16String* not easy to 
visually parse. The tf1 part is especially jarring to me, as we're 
having three very narrow symbols right next to each other.

You may also want to consider putting the most important bit first: the 
fact that it's a string. The encoding of such string is of secondary 
importance I'd say. So, that would suggest QString8 and QString16. As Qt 
uses UTF for all strings in principle, I'd suggest to document the odd 
one out by explicitly naming it. Perhaps QLatin1String would do? But 
wait! That's what we do already! We have the UTF version not mention 
it's encoding and the exception mentioning it. Perfect. Let's stick to that.

So yeah, I agree with Philippe.

André