I meant at compile time, if that was not clear.

On Wed, Nov 6, 2019, 17:30 Billy O'Neal (VC LIBS) <bion_at_[hidden]>
wrote:

> 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_[hidden]>
> *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]> <lib-bounces_at_[hidden]>
> on behalf of Tom Honermann via Lib <lib_at_[hidden]>
> <lib_at_[hidden]>
> *Sent:* Wednesday, November 6, 2019 1:12:48 PM
> *To:* Corentin <corentin.jabot_at_[hidden]> <corentin.jabot_at_[hidden]>
> *Cc:* Tom Honermann <tom_at_[hidden]> <tom_at_[hidden]>; C++ Library
> Evolution Working Group <lib-ext_at_[hidden]>
> <lib-ext_at_[hidden]>; Library Working Group <lib_at_[hidden]>
> <lib_at_[hidden]>; unicode_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]> 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]> 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
> <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]> <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 listLib-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 listLib-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 listUnicode_at_[hidden]://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>
>
>
>
>