<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 11/4/19 9:40 AM, Steve Downey wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJEGDKqqzNtXY6vQ4Yvoccy0zggOk+RipGyR++YnG507HeanHQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">I believe the wording around locale is merely
        warning that if μs isn't supported by the locale associated with
        a stream, then the results are unspecified, which is true, but
        unhelpful, and probably does not need to be in the normative
        wording for this.</div>
    </blockquote>
    I think it is helpful to make it clear that the implementation does
    not (should not) make such cases "work".<br>
    <blockquote type="cite"
cite="mid:CAJEGDKqqzNtXY6vQ4Yvoccy0zggOk+RipGyR++YnG507HeanHQ@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        <div>I'm unaware of any implementation that supports checking if
          string literals are actually encodable. All implementations
          are requirged to at least track \u00b5 until literals are
          encoded. This sound like an implementation that supports
          targeting non-unicode encodings of literals, such as MSVC,
          will have to use "us". <br>
        </div>
      </div>
    </blockquote>
    <p>I believe gcc at least will warn in cases where the source
      encoding and execution encoding are not the same.</p>
    <p>I would argue that MSVC can use "μs" when compiling with the
      /execution-charset:utf-8 or /utf-8 options (implicitly or
      explicitly) enabled.<br>
    </p>
    <p>Tom.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAJEGDKqqzNtXY6vQ4Yvoccy0zggOk+RipGyR++YnG507HeanHQ@mail.gmail.com"><br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Mon, Nov 4, 2019 at 9:03 AM
          Howard Hinnant &lt;<a href="mailto:howard.hinnant@gmail.com"
            moz-do-not-send="true">howard.hinnant@gmail.com</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"><br>
          On Nov 4, 2019, at 8:45 AM, Tom Honermann &lt;<a
            href="mailto:tom@honermann.net" target="_blank"
            moz-do-not-send="true">tom@honermann.net</a>&gt; wrote:<br>
          &gt; <br>
          &gt; On 11/4/19 7:18 AM, Howard Hinnant wrote:<br>
          &gt;&gt; On Nov 4, 2019, at 12:27 AM, Tom Honermann &lt;<a
            href="mailto:tom@honermann.net" target="_blank"
            moz-do-not-send="true">tom@honermann.net</a>&gt; wrote:<br>
          &gt;&gt;&gt; I suggest the following wording: (using
          terminology from P1859R0)<br>
          &gt;&gt;&gt; <br>
          &gt;&gt;&gt; If Period​::​type is micro, 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 charT, the unit suffix
          "us" is used instead of "μs".  &lt;ins&gt;If<br>
          &gt;&gt;&gt; "μs" is used 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
          std::codecvt facet that lacks conversion support for the
          character, then the  result is unspecified.&lt;/ins&gt;<br>
          &gt;&gt;&gt; <br>
          &gt;&gt; I’ve no objection to an issue, but your proposed
          wording explicitly involves two things I’m strongly against:<br>
          &gt;&gt; <br>
          &gt;&gt; 1.  Now the code has to check the locale, for this
          precision only.<br>
          &gt;&gt; <br>
          &gt;&gt; 2.  Now the code has different behavior between cout
          and ostringstream.  And the result of ostringstream is very
          commonly subsequently sent to cout (ostringstream is a common
          formatting aid).<br>
          &gt;&gt; <br>
          &gt;&gt; Imo, the proposed wording is much, much worse than
          the status-quo and I would vote strongly against it.<br>
          &gt; <br>
          &gt; No, the wording I proposed doesn't check for locale.  The
          execution character set is the character set used for string
          literals and is known at compile time; it is not the locale
          dependent run-time character set.<br>
          <br>
          <br>
          Here is the processed form of what you wrote (the deletes
          deleted, the inserts inserted):<br>
          <br>
          If Period​::​type is micro, but the character U+00B5 lacks
          representation in the execution character set for charT, the
          unit suffix "us" is used instead of "μs".  If "μs" is used 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 std::codecvt facet that lacks
          conversion support for the character, then the  result is
          unspecified.<br>
          <br>
          The phrase "or if the stream is imbued with a std::codecvt
          facet that…” implies that the implementation gets the locale
          of the stream, extracts the codecvt facet from it, and does
          something with it.<br>
          <br>
          I do not believe the streaming of durations of any precision
          should involve the stream’s locale.<br>
          <br>
          For microseconds precision the suffix should be “μs”, but at
          the vendor’s discretion may be “us” instead.<br>
          <br>
          I’m open to better ways of saying the sentence above.  The
          above sentence doesn’t (and shouldn’t) be stream-dependent or
          locale dependent.  It should not involve properties of the
          codecvt facet.<br>
          <br>
          Howard<br>
          <br>
        </blockquote>
      </div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>