Update normative references to ISO/IEC 10646 #1
Comments
|
That's p0417r1 and it was rejected in Kona 2017 (US 64/CA 9/GB 4 issue proceeding) |
|
[locale.stdcvt] is now deprecated, so not changing it is probably OK. |
|
Also, looking into history, it seems that updating the reference got mixed together with deprecating UCS. It's really an independent thing. |
|
It's not really an independent thing, is it? The standard cannot use the term "UCS-2" without a reference to 10646 from before 2011 because it doesn't have a normative definition since. Updating the edition of 10646 while keeping the UCS-2 references in the standard would just introduce the same problem we're trying to solve (namely, that "UTF-8", "UTF-16", and "UTF-32" are used without a normative definition) |
Thanks for that link. I did a little archaeology... The GB 4, US 64, and CA 9 comments are from P0488: Relevant meeting notes from the wiki:
I can't find mention of P0417 in any of the straw polls for Issaquah, Kona, or Toronto. It looks like CWG approved P0417R1, but it never got moved at plenary. |
|
http://wiki.edg.com/bin/view/Wg21kona2017/LWGTuesdayNight has the brief discussion where p0417 was not adopted. |
|
Ah, thanks. I managed to forget that TWiki actually has search capabilities... Also http://wiki.edg.com/bin/view/Wg21kona2017/LWGCommentStatus |
|
Damn, no wiki access. Regarding the comments...
I wonder how much software that will use C++20 relies on UCS-2 in a way that makes it not replaceable with UTF-16. Regardless, the reference to UCS-2 cannot stay, because it's simply not a thing. We could keep the behaviour by rewording those to use UTF-16 but failing when converting non-BMP characters to it. |
You will be granted access at Rapperswil 😄 I think we should propose removing http://eel.is/c++draft/depr.locale.stdcvt#req in C++20. |
|
Debian Code Search finds quite a few users of those facets: codecvt_utf8 codecvt_utf16 codecvt_utf8_utf16 - they will be caught without migration path if there is no replacement. The way I see it, the issue is that two of those facets are specified to convert N:1, and on the platform that has 16-bit wchar_t, they have no other option. Making all three N:M, as p0417r1 proposed, would've solved the issue (as they are not used with fstream, so they have no need to be N:1 in the first place) |
|
As mentioned at telecom, p0417r1 could probably be made more agreeable by changing "UCS2" to "implementation-defined", to keep the existing implementation divergence while unblocking the ISO 10646 version bump. |
It looks like almost all of those hits are in the gcc or libstdc++ implementation and testsuite for those facets. I only found two actual uses in the few minutes I spent browsing the hits. |
Indeed it does, thanks! We do, of course, need to provide replacement functionality for these facets at some point, but I don't think we'll be ready to do that in C++20. So the question is, is the existing usage significant enough to require a replacement prior to removal? These results suggest that may be the case. The proposal to remove these facets should probably include this data. |
|
So we voted P1025R1 into the draft at Rapperswil. Should we close this? I think so, and then perhaps open a new issue for "Smuggle Unicode Standard normative reference". |
|
Let's wait to close this until we see the updates appear in the WP that appears in the post-meeting mailing. We can then ensure the expected updates were correctly applied. As for adding a normative Unicode standard reference, https://github.com/rmartinho/sg16/blob/master/papers/d1097r0.md already does that, so can we rely on #15 to track doing so? The CWG feedback seems to be don't add it until we need it, so tracking it as a separate item doesn't seem so useful. I'm not too worried about forgetting to add it (when adding features that will need it). |
|
Closing this. I verified that the wording updates from P1025R1 appear in the current standard draft here: |
The C++ standard currently references ISO/IEC 10646-1:1993. That is, um, old.
There is, shall we say, an opportunity to improve this.
The text was updated successfully, but these errors were encountered: