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
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
