[Development] QUtf8String{, View}

Matthew Woehlke mwoehlke.floss at gmail.com
Fri May 15 19:52:49 CEST 2020


On 14/05/2020 21.12, Thiago Macieira wrote:
> On Thursday, 14 May 2020 07:41:45 PDT Marc Mutz via Development wrote:
>> Also, given a function like
>>
>>      setFoo(const QByteArray &);
>>
>> what does this actually expect? An UTF-8 string? A local 8-bit string?
>> An octet stream? A Latin-1 string? QByteArray is the jack of all these,
>> master of none.
> 
> Like that, it's just "array of bytes of an arbitrary encoding (or none)".
> There's still a reason to have QByteArray and it'll need to exist in
> networking and file I/O code. That means the string classes, if any, need to
> be convertible to QByteArray anyway.

I think we can learn from Python 3 here... QByteArray should go the way 
of QStringList, i.e. yes, it *should* be a QVector<byte>. Like 
QVector<QString>, it might (should) have additional methods, such as 
explicit conversion to/from QString (a la Python's encode/decode), but 
it should *not* have string-like manipulation (e.g. toUpper).

>> So, assuming the premise that QByteArray should not be string-ish
>> anymore, what do we want to have as the result type of QString::toUtf8()
>> and QString::toLatin1()? Do we really want mere bytes?

Yes. Maybe. Again, this is how Python 3 works.

It might make sense to have a QUtf8String class, but that should be 
distinct from, and not implicitly constructible from, QByteArray a.k.a. 
QVector<byte>. (Implicit conversion *to* QByteArray might be okay.)

(BTW, is 'byte' QByte or std::byte? Can we possibly achieve the latter?)

-- 
Matthew


More information about the Development mailing list