Date: Wed, 6 Nov 2019 17:30:26 +0000
Corentin’s PR says “if char (the execution encoding) can always represent µ for your implementation, use that. Otherwise use u.” Which means on my implementation where char can’t always represent such a thing as that is locale dependent. we will statically use u (and µ for wchar_t); but an implementation that assumes char is UTF-8 could use µ.
The LWG issue’s PR says “if the stream can detect that it is targeting a console or codecvt facet that don’t support µ, an implementation may use u, otherwise they use µ”. But streams have no means of doing that detection. (And the answer can even change if someone changes the streambuf)
Billy3
________________________________
From: Tom Honermann <tom_at_honermann.net>
Sent: Wednesday, November 6, 2019 5:14:18 PM
To: Billy O'Neal (VC LIBS) <bion_at_[hidden]>; lib_at_[hidden] <lib_at_[hidden]>; Corentin <corentin.jabot_at_[hidden]>
Cc: C++ Library Evolution Working Group <lib-ext_at_[hidden]>; unicode_at_[hidden] <unicode_at_[hidden]>
Subject: Re: [isocpp-lib] [SG16-Unicode] [isocpp-lib-ext] [time.duration.io] : Is stream insertion behavior locale dependent when Period::type is micro?
On 11/6/19 4:30 PM, Billy O'Neal (VC LIBS) wrote:
> Please read the wording again. Note that it says that, if those conditions are true, then the result is unspecified.
If “the wording” means the P/R of https://cplusplus.github.io/LWG/issue3314<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcplusplus.github.io%2FLWG%2Fissue3314&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639648909&sdata=7GBDeNaCU2%2B64mxLltJkFfdRuDybqgmOYQA4RPFWHRI%3D&reserved=0>, the wording there implies that we must make some effort to determine that the condition is true, which in practice we cannot do because the interface between streams and streambufs is public.
Yes, that is the wording I meant. The intent is to ensure the implementation does *not* have to put forth such effort. I don't understand where such an implication is coming from, but that wording has confused at least three experienced wordsmiths, so I acknowledge there is an issue, but I don't understand what it is.
I think it is important to say something here. Otherwise, one could claim that the terminal failing to display "μs" because it is configured for an incompatible encoding is non-conforming. Well, to the extent that the standard addresses such devices.
Tom.
Corentin’s P/R below seems to not have this concern.
Billy3
________________________________
From: Lib <lib-bounces_at_[hidden]><mailto:lib-bounces_at_[hidden]> on behalf of Tom Honermann via Lib <lib_at_[hidden]><mailto:lib_at_[hidden]>
Sent: Wednesday, November 6, 2019 1:12:48 PM
To: Corentin <corentin.jabot_at_[hidden]l.com><mailto:corentin.jabot_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]><mailto:tom_at_[hidden]>; C++ Library Evolution Working Group <lib-ext_at_[hidden]><mailto:lib-ext_at_[hidden]>; Library Working Group <lib_at_[hidden]><mailto:lib_at_[hidden]>; unicode_at_[hidden]<mailto:unicode_at_[hidden]> <unicode_at_[hidden]><mailto:unicode_at_[hidden]>
Subject: Re: [isocpp-lib] [SG16-Unicode] [isocpp-lib-ext] [time.duration.io] : Is stream insertion behavior locale dependent when Period::type is micro?
The intent of the wording is to say that implementors do *not* need to be aware of terminals or codecvt facets. Without this, the wording could be read that implementations must implement magic to make the character display correctly.
Please read the wording again. Note that it says that, if those conditions are true, then the result is unspecified.
Tom.
On Nov 6, 2019, at 12:07 PM, Corentin <corentin.jabot_at_[hidden]<mailto:corentin.jabot_at_[hidden]>> wrote:
Then I would just say associated execution encoding with charT
Extremely uncomfortable with involving stream, console or anything else not known at compile time
On Wed, 6 Nov 2019 at 04:51, Tom Honermann <tom_at_[hidden]<mailto:tom_at_[hidden]>> wrote:
On 11/6/19 8:30 AM, Howard Hinnant wrote:
You can comment the LWG issue (if you want) by emailing said comment to lwgchair_at_[hidden]<mailto:lwgchair_at_[hidden]>, specifying which issue you wish to comment and supplying the comment.
Howard
On Nov 5, 2019, at 10:32 PM, Corentin via Lib-Ext <lib-ext_at_[hidden]><mailto:lib-ext_at_[hidden]> wrote:
Not sure how to do that proceduraly but here is some alternative wording.
The "runtime" locale-tied encoding is *assumed to be* a super set of the execution encoding - to the extent the standard doesn't distinguish between the two
If Period::type is micro, but the <ins>abstract</ins> character <ins>µ , which has the universal character name </ins> U+00B5 cannot be represented in the <ins>execution</ins> encoding <del>used for</del><ins> associated with the character type </ins> charT, the unit suffix "us" is used instead of "µs".
Howard and I discussed the wording I proposed today and we're now on the same page with regard to the intent.
With regard to Corentin's suggested wording above, "abstract character" and "execution encoding" are not current terms in the standard (well, the former is inherited from our reference to the Unicode standard but is otherwise unused at present). P1859R0<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2Fp1859r0&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639658899&sdata=ZRSB0GKnWzhgzQArFZMtAvhJ912CIBttXg1lXijUgjQ%3D&reserved=0> does intend to standardize new terminology, but we don't yet have consensus for what the new terms should be named. I think we should avoid using candidate names until we have such consensus.
Tom.
On Mon, 4 Nov 2019 at 15:42, Tom Honermann via Lib-Ext <lib-ext_at_[hidden]><mailto:lib-ext_at_[hidden]> wrote:
A new LWG issue was filed for this question today:
- https://cplusplus.github.io/LWG/issue3314<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcplusplus.github.io%2FLWG%2Fissue3314&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639668895&sdata=uC3YRt9nkh4RHBan05r7vgp80RqZ9MTT3OS9H8MEDFY%3D&reserved=0>
This issue concerns the ostream inserters added for std::chrono::duration in C++20 and what the intended behavior is for a duration when period::type is micro.
[time.duration.io<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftime.duration.io&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639668895&sdata=KL8P5jLXGV%2FXWF1%2F11L8IiiCHY1Nf3IRL%2Fhnu%2BVtMcM%3D&reserved=0>]p4 states:
If Period::type is micro, but the character U+00B5 cannot be represented in the encoding used for charT, the unit suffix "us" is used instead of "μs".
The question is with regard to which one of the encodings used for charT is referred to here; the compile-time execution character set or the run-time locale dependent native character set?
The proposed resolution specifies that the compile-time execution character set is the intended one. My expectation is that this aligns with existing implementations, but I haven't checked.
Tom.
_______________________________________________
Lib-Ext mailing list
Lib-Ext_at_[hidden]<mailto:Lib-Ext_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639678891&sdata=q8STNMI8xDAbgpdthf8VgIbgNvzADEDmnmLJRYzQ8uc%3D&reserved=0>
Link to this post: http://lists.isocpp.org/lib-ext/2019/11/13309.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Flib-ext%2F2019%2F11%2F13309.php&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639688887&sdata=ZtRjYdN7d%2FeiuJezp8vyxOOtsOOZc0%2BqDXGoZq2tqCI%3D&reserved=0>
_______________________________________________
Lib-Ext mailing list
Lib-Ext_at_lists.isocpp.org<mailto:Lib-Ext_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639688887&sdata=o37Ay5VWpZ7hqbglGhSpsl0DbpKNm%2BP4YckKbNMvgCs%3D&reserved=0>
Link to this post: http://lists.isocpp.org/lib-ext/2019/11/13325.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Flib-ext%2F2019%2F11%2F13325.php&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639698882&sdata=DWLr80dJM2Zqg5Ad44m%2B%2BvQLN8sO%2B37DyJRnX5iDIas%3D&reserved=0>
_______________________________________________
SG16 Unicode mailing list
Unicode_at_[hidden]<mailto:Unicode_at_[hidden]std.org>
http://www.open-std.org/mailman/listinfo/unicode<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Funicode&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639708883&sdata=RQAtQ3ROTPGMOSZTLZjXw%2BdgQWD4FYdftkbYd4L4c24%3D&reserved=0>
The LWG issue’s PR says “if the stream can detect that it is targeting a console or codecvt facet that don’t support µ, an implementation may use u, otherwise they use µ”. But streams have no means of doing that detection. (And the answer can even change if someone changes the streambuf)
Billy3
________________________________
From: Tom Honermann <tom_at_honermann.net>
Sent: Wednesday, November 6, 2019 5:14:18 PM
To: Billy O'Neal (VC LIBS) <bion_at_[hidden]>; lib_at_[hidden] <lib_at_[hidden]>; Corentin <corentin.jabot_at_[hidden]>
Cc: C++ Library Evolution Working Group <lib-ext_at_[hidden]>; unicode_at_[hidden] <unicode_at_[hidden]>
Subject: Re: [isocpp-lib] [SG16-Unicode] [isocpp-lib-ext] [time.duration.io] : Is stream insertion behavior locale dependent when Period::type is micro?
On 11/6/19 4:30 PM, Billy O'Neal (VC LIBS) wrote:
> Please read the wording again. Note that it says that, if those conditions are true, then the result is unspecified.
If “the wording” means the P/R of https://cplusplus.github.io/LWG/issue3314<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcplusplus.github.io%2FLWG%2Fissue3314&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639648909&sdata=7GBDeNaCU2%2B64mxLltJkFfdRuDybqgmOYQA4RPFWHRI%3D&reserved=0>, the wording there implies that we must make some effort to determine that the condition is true, which in practice we cannot do because the interface between streams and streambufs is public.
Yes, that is the wording I meant. The intent is to ensure the implementation does *not* have to put forth such effort. I don't understand where such an implication is coming from, but that wording has confused at least three experienced wordsmiths, so I acknowledge there is an issue, but I don't understand what it is.
I think it is important to say something here. Otherwise, one could claim that the terminal failing to display "μs" because it is configured for an incompatible encoding is non-conforming. Well, to the extent that the standard addresses such devices.
Tom.
Corentin’s P/R below seems to not have this concern.
Billy3
________________________________
From: Lib <lib-bounces_at_[hidden]><mailto:lib-bounces_at_[hidden]> on behalf of Tom Honermann via Lib <lib_at_[hidden]><mailto:lib_at_[hidden]>
Sent: Wednesday, November 6, 2019 1:12:48 PM
To: Corentin <corentin.jabot_at_[hidden]l.com><mailto:corentin.jabot_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]><mailto:tom_at_[hidden]>; C++ Library Evolution Working Group <lib-ext_at_[hidden]><mailto:lib-ext_at_[hidden]>; Library Working Group <lib_at_[hidden]><mailto:lib_at_[hidden]>; unicode_at_[hidden]<mailto:unicode_at_[hidden]> <unicode_at_[hidden]><mailto:unicode_at_[hidden]>
Subject: Re: [isocpp-lib] [SG16-Unicode] [isocpp-lib-ext] [time.duration.io] : Is stream insertion behavior locale dependent when Period::type is micro?
The intent of the wording is to say that implementors do *not* need to be aware of terminals or codecvt facets. Without this, the wording could be read that implementations must implement magic to make the character display correctly.
Please read the wording again. Note that it says that, if those conditions are true, then the result is unspecified.
Tom.
On Nov 6, 2019, at 12:07 PM, Corentin <corentin.jabot_at_[hidden]<mailto:corentin.jabot_at_[hidden]>> wrote:
Then I would just say associated execution encoding with charT
Extremely uncomfortable with involving stream, console or anything else not known at compile time
On Wed, 6 Nov 2019 at 04:51, Tom Honermann <tom_at_[hidden]<mailto:tom_at_[hidden]>> wrote:
On 11/6/19 8:30 AM, Howard Hinnant wrote:
You can comment the LWG issue (if you want) by emailing said comment to lwgchair_at_[hidden]<mailto:lwgchair_at_[hidden]>, specifying which issue you wish to comment and supplying the comment.
Howard
On Nov 5, 2019, at 10:32 PM, Corentin via Lib-Ext <lib-ext_at_[hidden]><mailto:lib-ext_at_[hidden]> wrote:
Not sure how to do that proceduraly but here is some alternative wording.
The "runtime" locale-tied encoding is *assumed to be* a super set of the execution encoding - to the extent the standard doesn't distinguish between the two
If Period::type is micro, but the <ins>abstract</ins> character <ins>µ , which has the universal character name </ins> U+00B5 cannot be represented in the <ins>execution</ins> encoding <del>used for</del><ins> associated with the character type </ins> charT, the unit suffix "us" is used instead of "µs".
Howard and I discussed the wording I proposed today and we're now on the same page with regard to the intent.
With regard to Corentin's suggested wording above, "abstract character" and "execution encoding" are not current terms in the standard (well, the former is inherited from our reference to the Unicode standard but is otherwise unused at present). P1859R0<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2Fp1859r0&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639658899&sdata=ZRSB0GKnWzhgzQArFZMtAvhJ912CIBttXg1lXijUgjQ%3D&reserved=0> does intend to standardize new terminology, but we don't yet have consensus for what the new terms should be named. I think we should avoid using candidate names until we have such consensus.
Tom.
On Mon, 4 Nov 2019 at 15:42, Tom Honermann via Lib-Ext <lib-ext_at_[hidden]><mailto:lib-ext_at_[hidden]> wrote:
A new LWG issue was filed for this question today:
- https://cplusplus.github.io/LWG/issue3314<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcplusplus.github.io%2FLWG%2Fissue3314&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639668895&sdata=uC3YRt9nkh4RHBan05r7vgp80RqZ9MTT3OS9H8MEDFY%3D&reserved=0>
This issue concerns the ostream inserters added for std::chrono::duration in C++20 and what the intended behavior is for a duration when period::type is micro.
[time.duration.io<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftime.duration.io&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639668895&sdata=KL8P5jLXGV%2FXWF1%2F11L8IiiCHY1Nf3IRL%2Fhnu%2BVtMcM%3D&reserved=0>]p4 states:
If Period::type is micro, but the character U+00B5 cannot be represented in the encoding used for charT, the unit suffix "us" is used instead of "μs".
The question is with regard to which one of the encodings used for charT is referred to here; the compile-time execution character set or the run-time locale dependent native character set?
The proposed resolution specifies that the compile-time execution character set is the intended one. My expectation is that this aligns with existing implementations, but I haven't checked.
Tom.
_______________________________________________
Lib-Ext mailing list
Lib-Ext_at_[hidden]<mailto:Lib-Ext_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639678891&sdata=q8STNMI8xDAbgpdthf8VgIbgNvzADEDmnmLJRYzQ8uc%3D&reserved=0>
Link to this post: http://lists.isocpp.org/lib-ext/2019/11/13309.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Flib-ext%2F2019%2F11%2F13309.php&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639688887&sdata=ZtRjYdN7d%2FeiuJezp8vyxOOtsOOZc0%2BqDXGoZq2tqCI%3D&reserved=0>
_______________________________________________
Lib-Ext mailing list
Lib-Ext_at_lists.isocpp.org<mailto:Lib-Ext_at_[hidden]>
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639688887&sdata=o37Ay5VWpZ7hqbglGhSpsl0DbpKNm%2BP4YckKbNMvgCs%3D&reserved=0>
Link to this post: http://lists.isocpp.org/lib-ext/2019/11/13325.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Flib-ext%2F2019%2F11%2F13325.php&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639698882&sdata=DWLr80dJM2Zqg5Ad44m%2B%2BvQLN8sO%2B37DyJRnX5iDIas%3D&reserved=0>
_______________________________________________
SG16 Unicode mailing list
Unicode_at_[hidden]<mailto:Unicode_at_[hidden]std.org>
http://www.open-std.org/mailman/listinfo/unicode<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Funicode&data=02%7C01%7Cbion%40microsoft.com%7C9247a018118d4bfe9a0508d762dcc3f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086572639708883&sdata=RQAtQ3ROTPGMOSZTLZjXw%2BdgQWD4FYdftkbYd4L4c24%3D&reserved=0>
Received on 2019-11-06 18:30:31