[Development] char8_t summary?

[Matthew Woehlke]

On 11/07/2019 15.01, Thiago Macieira wrote:
> On Thursday, 11 July 2019 13:41:49 -03 Matthew Woehlke wrote:
>> On 11/07/2019 05.05, Mutz, Marc via Development wrote:
>>> There is a cost associated with another string class, too, and it's
>>> combinatorial explosion. Even when we have all view types
>>> (QLatin1StringView, QUtf8StringView, QStringView), consider the overload
>>> set of QString::replace(), ignoring the (ptr, size) variants:
>>>
>>>    {QL1V, QU8V, QSV, QChar} x {QL1V, QU8V, QSV, QChar}
>>>
>>> that's 16 overloads. And that's without a possible QUtf32StringView.
>>
>> So?
>>
>> The right way to handle this is for those methods to be templated, in
>> which case a) the code only needs to be written O(1) times, not O(N)
>> times, and b) users can potentially specialize for their own string
>> types as well.
> 
> Except that the whole point of those methods is that they can be more 
> efficient when the encoding is known and therefore templating won't help. 

So those cases can employ specializations. Or, perhaps better, wrap the
implementation bits where it matters in `if constexpr`.

> Templating won't make overload resolution any faster, but will make 
> compilation times slower.

For Qt, yes. This could be significantly (entirely?) mitigated with
explicit, external instantiations, such that only the one source in Qt
itself that compiles the instantiations is significantly affected.

> And if we want to make use of the fact that a string 
> is UTF-8, the templates won't work.

Eh? char8_t is a detectable and distinct type. (Wasn't that the whole
point of this thread?) So is QUtf8String if such a thing were to come
into existence.

>> If done cleverly, even the (pointer, size) variants should be able to
>> wrap the arguments in a View, such that those method definitions are
>> trivial.
> 
> View = (pointer,size) pair.

I meant that e.g. it would not be hard to make:

  foo(CharType const* s, SizeType L)

...be a simple wrapper around:

  foo(View<CharType>::type s);

...which is itself either a template (per above), or several
non-template functions taking various types of views (status quo). No
combinatorial explosion of code per possible pointer type.

-- 
Matthew