<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 <<a href="mailto:howard.hinnant@gmail.com"
moz-do-not-send="true">howard.hinnant@gmail.com</a>>
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 <<a
href="mailto:tom@honermann.net" target="_blank"
moz-do-not-send="true">tom@honermann.net</a>> wrote:<br>
> <br>
> On 11/4/19 7:18 AM, Howard Hinnant wrote:<br>
>> On Nov 4, 2019, at 12:27 AM, Tom Honermann <<a
href="mailto:tom@honermann.net" target="_blank"
moz-do-not-send="true">tom@honermann.net</a>> wrote:<br>
>>> I suggest the following wording: (using
terminology from P1859R0)<br>
>>> <br>
>>> If Period::type is micro, but the character
U+00B5 <del>cannot be represented in the encoding
used</del><ins>lacks representation in the
execution character set</ins> for charT, the unit suffix
"us" is used instead of "μs". <ins>If<br>
>>> "μ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.</ins><br>
>>> <br>
>> I’ve no objection to an issue, but your proposed
wording explicitly involves two things I’m strongly against:<br>
>> <br>
>> 1. Now the code has to check the locale, for this
precision only.<br>
>> <br>
>> 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>
>> <br>
>> Imo, the proposed wording is much, much worse than
the status-quo and I would vote strongly against it.<br>
> <br>
> 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>