-----Original Message----- From: Thiago Macieira <thiago.macie...@intel.com> > > I am not completely convinced of the benefit of adding of an owning UTF-8 > string class, though I very much agree with a view over UTF-8 strings. > The reason is not the string class itself (alone it is definitely useful), > but the fact that it would muddy the waters as to what string classes one > should use in API. > We might end up with some API using UTF-8 and some UTF-16.
Indeed, this is already the case : QJsonDocument::toJson() returns a QByteArray on which users can conveniently call toUpper() until some data from the field makes them understand it does not work... Working for a regulated industry, getting rid of potential bugs is my #1 concern, not that of having more fancy utf8 features! However, if deriving a QUtf8String from QByteArray is inappropriate (of which I am not totally convinced... cannot see a Liskov-Substitution-Principle violation in this case), I understand the task may be daunting. It may be argued too that COW is not interesting for such strings and APIs can be fixed by using u8string, but then, you ask Qt users to master both QString and std::string like APIs... Just my 2c, Arnaud _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
