[Development] QAnyString(View) (was: Re: Views in APIs)

[Marc Mutz]

On 2020-05-13 11:53, Ville Voutilainen wrote:
> On Wed, 13 May 2020 at 12:46, Marc Mutz via Development
> <development at qt-project.org> wrote:
>> In the not so hypothetical case that Qt is used to visualize results 
>> of
>> some business calculations, chances are that thrid-party libraries 
>> will
>> use std::string or std::u16string, and not QString, requiring the use 
>> of
>> QString::fromStdString() to pass these to a QString API. Had the API
>> taken QStringView, no extra code would have been necessary.
> 
> Wait, what? How can QStringView view a std::string?

Touché.

I was a bit sloppy there.

There was an idea floating around this mailing-list next last year or 
so, to have one string class for different encodings. Of course, in and 
of itself, that's nonsense, because performance is not predicatable 
anymore. But for a really user-friendly API (as opposed to 
implementation-friendly), we could have most functions that now take 
QString, and are not candidates for overloading on QStringView, 
QUtf8StringView and QLatin1StringView, take a variant<QStringView, 
QUtf8StringView(, QLatin1StringView)>-like container, called QAnyString. 
They would then internally convert this into the encoding they need. I 
believe this would be an acceptable compromise between the 
many-small-narrowly-focused-classes and 
one-string-class-to-rule-them-all camps, as it would reduce the number 
of overloads in non-performance-critical areas while maintaining the 
flexibility that taking QString now offers. It's how multi-arg() is 
currently implemented, except it's private API now, and not anywhere 
near something that could become public API.

Thanks,
Marc