<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">By "device", do you mean a display
      device, e.g., a console/terminal?  If the intent is that the
      implementor can fall back at run-time, then that does seem to
      apply a locale dependency to me since whether "μs" can actually be
      displayed is locale dependent.  (Actually, it is worse than locale
      dependent since it depends on console/terminal configuration as
      well).<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">I suspect what we really want to depend
      on here is the execution character set known at compile time.  If
      the characters can be represented in that associated character
      set, then whether they can be displayed correctly depends on
      having a sane choice for execution character set and run-time
      locale.  In this sense, this touches on issues we're working to
      address in:</div>
    <div class="moz-cite-prefix">-  P1854R0: Conversion to execution
      encoding should not lead to loss of meaning</div>
    <div class="moz-cite-prefix">   - This paper proposes that
      character/string literals are ill-formed if they contain a
      character not representable in the corresponding execution
      character set; the intent of the wording we're discussing is to
      avoid the problems this paper intends to address.<br>
    </div>
    <div class="moz-cite-prefix">-  P1859R0: Standard terminology for
      execution character set encodings</div>
    <div class="moz-cite-prefix">   - We've discussed adding a
      requirement or at least a note to this paper stating that the
      contents of a character/string literal must be representable in
      the dynamic (locale dependent) encoding to prevent ... something
      (unspecified behavior?)</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">I suggest the following wording: (using
      terminology from P1859R0)</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">
      <div class="itemdescr">
        <div class="moz-cite-prefix">If <tt><span class="texttt">Period<span
                class="operator">​::​</span>type</span></tt> is <tt><span
              class="texttt">micro</span></tt>,
          but the character U+00B5 &lt;del&gt;cannot be represented in
          the encoding used&lt;/del&gt;&lt;ins&gt;lacks representation
          in the execution character set&lt;/ins&gt; for <tt><span
              class="texttt">charT</span></tt>,
          the unit suffix <tt><span class="texttt"><span
                class="literal">"us"</span></span></tt> is used instead
          of <tt><span class="texttt"><span class="literal">"μs"</span></span></tt><span
            class="texttt"><span class="literal">.  &lt;ins&gt;If</span></span><br>
          <tt><span class="texttt"><span class="literal"><tt><span
                    class="texttt"><span class="literal">"μs"</span></span></tt></span></span></tt><span
            class="texttt"><span class="literal"><span class="texttt"><span
                  class="literal"> is used</span></span></span></span>
          but the dynamic encoding lacks representation for U+00B5 and
          the stream is associated with a terminal or console, or if the
          stream is imbued with a <tt>std::codecvt</tt> facet that
          lacks conversion support for the character, then the  result
          is unspecified.&lt;/ins&gt;<br>
        </div>
      </div>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Looking for feedback, but am leaning
      towards filing an LWG issue.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Tom.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 11/3/19 9:38 AM, Howard Hinnant
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:9C16A64E-A6A7-4CA8-B37E-B2879D9B52EF@gmail.com">
      <pre class="moz-quote-pre" wrap="">If for some reason the device can’t deal with Unicode, the vendor can fall back to “us” in the basic character set.

Howard

On Nov 3, 2019, at 11:52 AM, Steve Downey <a class="moz-txt-link-rfc2396E" href="mailto:sdowney@gmail.com">&lt;sdowney@gmail.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
If the encoding is intended as the one used for literals of type charT, then locale does not have to be involved.  That does run the risk of "?s" being produced instead of "μs" .
If the encoding is latin-7, is it supposed to produce "μs"?

On Sun, Nov 3, 2019, 09:47 Howard Hinnant <a class="moz-txt-link-rfc2396E" href="mailto:howard.hinnant@gmail.com">&lt;howard.hinnant@gmail.com&gt;</a> wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">The intent is to use Unicode to get “μs” without involving a locale.  That would be UTF-8 for char, UTF-16 for a 2 byte wchar_t and UTF-32 for a 4 byte wchar_t.  And if for some reason the device can’t deal with Unicode, the vendor can fall back to “us” in the basic character set.  In either event, it is not intended to involve a locale, and specifically doesn’t not involve the ctype facet and widening/narrowing.  I’m not sure I would call it implementation defined as the vendor isn’t required to document it.  But the vendor can choose between the Unicode output, or the “us” approximation.

Feel free to submit an issue, but if you do I strongly recommend suggested wording as the LWG has already been over this paragraph in detail and the current wording is a product of that review.

Howard

</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">On Nov 3, 2019, at 8:16 AM, Tom Honermann <a class="moz-txt-link-rfc2396E" href="mailto:tom@honermann.net">&lt;tom@honermann.net&gt;</a> wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">
I just came across [time.duration.io]p4:

</pre>
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">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".
</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">
How is the determination as to whether the character can be represented to be done?  It seems this would involve consulting the locale.  Or is this effectively implementation defined behavior?

Perhaps this is worth an LWG issue to at least clarify the behavior?

Tom.

</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
_______________________________________________
SG16 Unicode mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Unicode@isocpp.open-std.org">Unicode@isocpp.open-std.org</a>
<a class="moz-txt-link-freetext" href="http://www.open-std.org/mailman/listinfo/unicode">http://www.open-std.org/mailman/listinfo/unicode</a>
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
SG16 Unicode mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Unicode@isocpp.open-std.org">Unicode@isocpp.open-std.org</a>
<a class="moz-txt-link-freetext" href="http://www.open-std.org/mailman/listinfo/unicode">http://www.open-std.org/mailman/listinfo/unicode</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>