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://cplusplus.github.io/LWG/issue3314>, 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]> on behalf of Tom Honermann
> via Lib <lib_at_[hidden]>
> *Sent:* Wednesday, November 6, 2019 1:12:48 PM
> *To:* Corentin <corentin.jabot_at_[hidden]>
> *Cc:* Tom Honermann <tom_at_[hidden]>; C++ Library Evolution Working
> Group <lib-ext_at_[hidden]>; Library Working Group
> <lib_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?
> 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 tolwgchair_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%7Cb9a77991a8d746c6e51708d762bb0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086427832584449&sdata=TTWf1hWjEPQIAlivJ1zDaXlH5pA%2F1QmEvdoTksUZKws%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%7Cb9a77991a8d746c6e51708d762bb0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086427832584449&sdata=ipwRAI%2Fb6Kp0NMD8%2Fk4x1yl%2Fp8a0Fxn%2FbGS8h3smGX4%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%7Cb9a77991a8d746c6e51708d762bb0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086427832594448&sdata=PmBavf7s8RWGBrufzaawVpaR5tleqhCScrmOQ4hkhqI%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%7Cb9a77991a8d746c6e51708d762bb0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086427832604456&sdata=f2RY2SSHO4qomK03tSv4T6kIod3gBYIbHqHF36lvGQU%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%7Cb9a77991a8d746c6e51708d762bb0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086427832604456&sdata=a1DrtNRegryVfJl5NcA8IX%2FbN5iaTN96z69Iw0FZBU4%3D&reserved=0>
>>>> _______________________________________________
>>>> 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%7Cb9a77991a8d746c6e51708d762bb0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086427832614463&sdata=xo7lnqDwW5a%2Frfo9yqDxgciliuyA0iE%2B0mY%2BUaTbRAU%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%7Cb9a77991a8d746c6e51708d762bb0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086427832614463&sdata=fywBIv%2B%2BWp1boJyXPTUyflRSSp6TBtu32mDEw1gvxN4%3D&reserved=0>
>>>
>>> _______________________________________________
>>> SG16 Unicode mailing list
>>> Unicode_at_[hidden] <mailto:Unicode_at_[hidden]>
>>> 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%7Cb9a77991a8d746c6e51708d762bb0c96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086427832624471&sdata=Mq6%2Bin7d%2By5dgwCn7XpnC8ZUx4qHb777%2FyQfwccdP64%3D&reserved=0>
>>
>>