Date: Wed, 6 Nov 2019 08:30:14 +0000
You can comment the LWG issue (if you want) by emailing said comment to 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]> 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".
>
>
>> On Mon, 4 Nov 2019 at 15:42, Tom Honermann via Lib-Ext <lib-ext_at_[hidden]> wrote:
>> A new LWG issue was filed for this question today:
>> - https://cplusplus.github.io/LWG/issue3314
>>
>> 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]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]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2019/11/13309.php
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2019/11/13325.php
Howard
On Nov 5, 2019, at 10:32 PM, Corentin via Lib-Ext <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".
>
>
>> On Mon, 4 Nov 2019 at 15:42, Tom Honermann via Lib-Ext <lib-ext_at_[hidden]> wrote:
>> A new LWG issue was filed for this question today:
>> - https://cplusplus.github.io/LWG/issue3314
>>
>> 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]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]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2019/11/13309.php
> _______________________________________________
> Lib-Ext mailing list
> Lib-Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2019/11/13325.php
Received on 2019-11-06 09:30:17