I am building ICU with the HEAD of gcc gcc (GCC) 10.0.1 20200211. When I try to compile with the C+20 support `-std=gnu+2a`, I get the following kind of compilation error:
From the C++ change proposal auther, this kind of conversion is not allowed anymore: https://stackoverflow.com/questions/57402464/is-c20-char8-t-the-same-as-our-old-char/57453713#57453713
I knew that this incompatible change was coming to C++ at some point
I propose that we add some strategic, version-conditional overloads to reduce the number of reinterpret_cast’s that we and everyone else needs. Please take a look.
FYI http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r0.html “char8_t backward compatibility remediation“
The simplest possible solution in the short term is to simply disable the new features completely. Clang and gcc will allow disabling char8_t features in both the language and standard library, via a -fno-char8_t option. It is expected that Microsoft and EDG based compilers will offer a similar option.
This option should be considered a short-term solution to enable testing existing C++17 code compiled as C++20 with minimal effort. This isn't a viable long-term option as continued use would potentially complicate composition with code that depends on the new features.
Adding function overloads that accept char8_t based types is an effective step towards full migration to C++20. Ideally, older char based functions would eventually be removed.
(Of course, in a library with stable API we can never remove existing functions.)
Thanks for your interesting answer.
I read you proposal and I fully agree it is far better than what I proposed in the PR. On my side, I need this on version 66. Is there already a branch that I could cherry-pick the change you propose from ?
ICU 66 is a minimal release focused on Unicode 13. There will be no new API other than what we need for that.
I would also prefer to not make the fairly extensive changes in your PR for ICU 66 when some (many?) of them will not be necessary with the new API in 67. I will bring this up in the committee. I will also take a closer look at your PR and suggest smaller changes.
Discussed in committee. Please retarget your PR and add the commit message prefix, then we approve & merge for 66.