<div dir="ltr">Then I would just say associated execution encoding with charT<div><br></div><div>Extremely uncomfortable with involving stream, console or anything else not known at compile time  </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 6 Nov 2019 at 04:51, Tom Honermann &lt;<a href="mailto:tom@honermann.net">tom@honermann.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    On 11/6/19 8:30 AM, Howard Hinnant wrote:<br>
    <blockquote type="cite">
      <pre>You can comment the LWG issue (if you want) by emailing said comment to <a href="mailto:lwgchair@gmail.com" target="_blank">lwgchair@gmail.com</a>, specifying which issue you wish to comment and supplying the comment.

Howard

On Nov 5, 2019, at 10:32 PM, Corentin via Lib-Ext <a href="mailto:lib-ext@lists.isocpp.org" target="_blank">&lt;lib-ext@lists.isocpp.org&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre>Not sure how to do that proceduraly but here is some alternative wording.
The &quot;runtime&quot; locale-tied encoding is *assumed to be* a super set of the execution encoding - to the extent the standard doesn&#39;t distinguish between the two


If Period::type is micro, but the &lt;ins&gt;abstract&lt;/ins&gt; character &lt;ins&gt;µ , which has the universal character name &lt;/ins&gt; U+00B5 cannot be represented in the &lt;ins&gt;execution&lt;/ins&gt; encoding &lt;del&gt;used for&lt;/del&gt;&lt;ins&gt; associated with the character type &lt;/ins&gt; charT, the unit suffix &quot;us&quot; is used instead of &quot;µs&quot;.</pre>
      </blockquote>
    </blockquote>
    <br>
    <div>Howard and I discussed the wording I
      proposed today and we&#39;re now on the same page with regard to the
      intent.<br>
    </div>
    <div><br>
    </div>
    <div>With regard to Corentin&#39;s suggested
      wording above, &quot;abstract character&quot; and &quot;execution encoding&quot; 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).  <a href="http://wg21.link/p1859r0" target="_blank">P1859R0</a> does intend to
      standardize new terminology, but we don&#39;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.<br>
    </div>
    <div><br>
    </div>
    <div>Tom.<br>
    </div>
    <div><br>
    </div>
    <blockquote type="cite">
      <blockquote type="cite">
        <pre></pre>
        <blockquote type="cite">
          <pre>On Mon, 4 Nov 2019 at 15:42, Tom Honermann via Lib-Ext <a href="mailto:lib-ext@lists.isocpp.org" target="_blank">&lt;lib-ext@lists.isocpp.org&gt;</a> wrote:
A new LWG issue was filed for this question today:
- <a href="https://cplusplus.github.io/LWG/issue3314" target="_blank">https://cplusplus.github.io/LWG/issue3314</a>

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.

[<a href="http://time.duration.io" target="_blank">time.duration.io</a>]p4 states:


</pre>
          <blockquote type="cite">
            <pre>If Period​::​type is micro, but the character U+00B5 cannot be represented in the encoding used for charT,           the unit suffix &quot;us&quot; is used instead of &quot;μs&quot;.

</pre>
          </blockquote>
          <pre>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&#39;t checked.

Tom.

</pre>
        </blockquote>
        <pre>_______________________________________________
Lib-Ext mailing list
<a href="mailto:Lib-Ext@lists.isocpp.org" target="_blank">Lib-Ext@lists.isocpp.org</a>
Subscription: <a href="https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext" target="_blank">https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext</a>
Link to this post: <a href="http://lists.isocpp.org/lib-ext/2019/11/13309.php" target="_blank">http://lists.isocpp.org/lib-ext/2019/11/13309.php</a>
_______________________________________________
Lib-Ext mailing list
<a href="mailto:Lib-Ext@lists.isocpp.org" target="_blank">Lib-Ext@lists.isocpp.org</a>
Subscription: <a href="https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext" target="_blank">https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext</a>
Link to this post: <a href="http://lists.isocpp.org/lib-ext/2019/11/13325.php" target="_blank">http://lists.isocpp.org/lib-ext/2019/11/13325.php</a>
</pre>
      </blockquote>
      <pre></pre>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
SG16 Unicode mailing list
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank">Unicode@isocpp.open-std.org</a>
<a href="http://www.open-std.org/mailman/listinfo/unicode" target="_blank">http://www.open-std.org/mailman/listinfo/unicode</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </div>

</blockquote></div>