[Development] char8_t summary?

[André Pönitz]

On Sun, Jul 14, 2019 at 08:28:58AM +0200, Mutz, Marc via Development wrote:
> > As I understood the template suggestion, it’s more about not having to
> > add 64 different overloads (or several more string classes) to the Qt
> > API, and less about unifying all implementations into a single set of
> > algorithms.
> 
> [I'm replying to Volker, but this should be read as replying to everyone,
> and 'you' should be read as the plural form]

Thanks for this clarification. It really helps.
 
> [...]
> But that doesn't reduce the number of overloads.

Has having this thin wrapper around the "usual suspects" of string-like
arguments as normal case of argument passing been considered?

This could be something like a string view with a few bits spent on
encoding infomation

This effectively eats the "free" implicit type conversion when passing an
argument but history (introduction of QStringBuilder) has shown that while
not completely source compatible, it was fairly harmless.

QStringBuilder itself already uses up the free conversion, but could
get an operator xxx() to produce the new argument tyoe, even can keep 
track of the encodings of the parts to help with provide the right
encoding bits.


>    template <typename Prefix>
>        requires std::is_convertible_v<Prefix, QStringView // || ...
> Qtf8StringView, || ... QLatin1StringView  ...
>    Q_ALWAYS_INLINE
>    bool endsWith(Prefix &p) const {
>        return QtPrivate::endsWith(*this,
> QtPrivate::qStringLikeToStringView(p));
>    }
> 
> with a qStringLikeToStringView() similar to the one in 181620.

The looks kind of related, just that the qStringLikeToStringView() should
not need to be end up explicitly written multiple times on the receiver
side, but be done implicitly in the conversion of the arguments in the
function call.

Andre'