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]> 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], 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]> <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 <http://wg21.link/p1859r0> 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]> <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 listLib-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 listLib-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
>
>
> _______________________________________________
> SG16 Unicode mailing listUnicode_at_[hidden]://www.open-std.org/mailman/listinfo/unicode
>
>
>