[Development] Oslo, we have a problem</apollo 13> [char8_t]

[Mutz, Marc]

On 2019-07-06 17:31, Fabian Kosmale wrote:
> Yes,
> 
> in hindsight this doesn't scale and it was also totally backwards. The
> issue is that the char8_t overload introduces ambiguity in the
> overload set, so instead of adding more overloads we should just
> remove it unless it really matches. So just add an overload taking a
> generic T and SFINAE it out as needed by testing for std::is_same_v<T,
> const char8_t*
> 
> As you can see at https://godbolt.org/z/SMEeBC , this handles 0, NULL
> and nullptr just fine, as well as u8 string literals and normal string
> literals.

Yes, that's how I wrote QStringView's QString ctor to allow overloading 
functions on QString and QStringView. In QStringView, it's just one 
ctor, though. For char8_t, we're talking 100s of functions taking const 
char* in Qt APIs. I'm not so much concerned about the carnage of 
templates that ensures from this (I like them), I'm concerned about 
compile times sky-rocketing, and docs becoming a mess.

> Though, if the compilers are implementing the behaviour correctly,
> maybe the right course of action is to actually complain to the
> committee that their change breaks code…

AFAIU, this is a conscious break.

Thanks,
Marc