<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/6/19 10:20 PM, Billy O'Neal (VC
LIBS) wrote:<br>
</div>
<blockquote type="cite"
cite="mid:MW2PR2101MB1098CA26A24CE993A83B2725CB790@MW2PR2101MB1098.namprd21.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:"Yu Gothic";
        panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"\@Yu Gothic";
        panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
<div class="WordSection1">
<p>> That isn't what it (is intended to) say, nor how I read
it. </p>
<p>Then remove the qualifications about terminals or codecvt
facets and talk only about the execution character set, and
things are OK. (As Corentin’s PR does)</p>
<p>> The intent of the wording was to allow Microsoft to use
"µs" when the compiler is invoked with
/execution-charset:utf-8 and to use "us" otherwise.<o:p></o:p></p>
<p class="MsoNormal">Given that UTF-8 support is still a rarely
used user opt-in at this time only available on recent
versions of Windows 10, it isn’t an assumption the library is
going to be able to make soon (i.e. the next decade)</p>
</div>
</blockquote>
<p>The library doesn't need to assume. An example implementation
(ignoring support for non-char types) could be:<br>
</p>
<pre>template<class traits, class Rep, class Period><tt>
void print_fancy_suffix</tt><tt>(basic_ostream<char, traits>& os, const duration<Rep, Period>& d)</tt><tt>
{</tt><tt>
static const char micro_sign[] = "\u00B5s";</tt><tt>
if (as_unsigned(micro_sign[0]) == 0xC2</tt><tt>u &&</tt><tt>
as_unsigned(micro_sign[1]) == 0xB5u)</tt><tt>
{</tt><tt>
// execution character set smells like UTF-8.</tt><tt>
os << </tt><tt>d.count() << micro_sign;</tt><tt>
} else {</tt><tt>
// execution character set smells like bad.</tt><tt>
</tt><tt><tt>os << </tt><tt>d.count() << "us";</tt></tt><tt>
}</tt><tt>
}</tt>
</pre>
<p>There are, of course, better ways to do this if the compiler has
the ability to inform the library what the execution character set
really is (e.g., a predefined macro).</p>
<p>I'm not arguing for any particular choice on Microsoft's part.<br>
</p>
<p>I think the Windows 10 comment is only relevant with respect to
the run-time locale and choice of encoding for the
console/terminal. Execution character set is independent of both
of those.<br>
</p>
<p>Tom.<br>
</p>
<blockquote type="cite"
cite="mid:MW2PR2101MB1098CA26A24CE993A83B2725CB790@MW2PR2101MB1098.namprd21.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Billy3</p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
color="#000000" face="Calibri, sans-serif"><b>From:</b> Tom
Honermann <a class="moz-txt-link-rfc2396E" href="mailto:tom@honermann.net"><tom@honermann.net></a><br>
<b>Sent:</b> Wednesday, November 6, 2019 5:38:34 PM<br>
<b>To:</b> Billy O'Neal (VC LIBS) <a class="moz-txt-link-rfc2396E" href="mailto:bion@microsoft.com"><bion@microsoft.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:lib@lists.isocpp.org">lib@lists.isocpp.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:lib@lists.isocpp.org"><lib@lists.isocpp.org></a>; Corentin
<a class="moz-txt-link-rfc2396E" href="mailto:corentin.jabot@gmail.com"><corentin.jabot@gmail.com></a><br>
<b>Cc:</b> C++ Library Evolution Working Group
<a class="moz-txt-link-rfc2396E" href="mailto:lib-ext@lists.isocpp.org"><lib-ext@lists.isocpp.org></a>; <a class="moz-txt-link-abbreviated" href="mailto:unicode@isocpp.open-std.org">unicode@isocpp.open-std.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:unicode@open-std.org"><unicode@open-std.org></a><br>
<b>Subject:</b> Re: [isocpp-lib] [SG16-Unicode]
[isocpp-lib-ext] [time.duration.io] : Is stream insertion
behavior locale dependent when Period::type is micro?</font>
<div> </div>
</div>
<div style="background-color:#FFFFFF">
<div class="x_moz-cite-prefix">On 11/6/19 5:30 PM, Billy O'Neal
(VC LIBS) wrote:<br>
</div>
<blockquote type="cite">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>
<!--
@font-face
        {font-family:"Cambria Math"}
@font-face
        {font-family:"Yu Gothic"}
@font-face
        {font-family:Calibri}
@font-face
        {}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:windowtext}
.x_MsoChpDefault
        {}
@page WordSection1
        {margin:1.0in 1.0in 1.0in 1.0in}
div.x_WordSection1
        {}
-->
</style>
<div class="x_WordSection1">
<p class="x_MsoNormal">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 µ.<br>
<br>
</p>
<p class="x_MsoNormal">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)</p>
</div>
</blockquote>
<p>That isn't what it (is intended to) say, nor how I read it.
It states that the suffix is determined by the execution
character set (the character set used for string literals and
known at compile time); that is in the first sentence. The
second sentence acknowledges that if the native character set
(the run-time locale dependent character set) lacks
representation for the character, then all bets are off with
regard to how the character is actually displayed (or
converted by a codecvt facet).</p>
<p>The intent of the wording was to allow Microsoft to use "µs"
when the compiler is invoked with /execution-charset:utf-8 and
to use "us" otherwise.<br>
</p>
<p>Tom.<br>
</p>
<blockquote type="cite">
<div class="x_WordSection1">
<p class="x_MsoNormal"> </p>
<p class="x_MsoNormal">Billy3</p>
<p class="x_MsoNormal"> </p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font
style="font-size:11pt" color="#000000" face="Calibri,
sans-serif"><b>From:</b> Tom Honermann
<a class="x_moz-txt-link-rfc2396E"
href="mailto:tom@honermann.net" moz-do-not-send="true"><tom@honermann.net></a><br>
<b>Sent:</b> Wednesday, November 6, 2019 5:14:18 PM<br>
<b>To:</b> Billy O'Neal (VC LIBS) <a
class="x_moz-txt-link-rfc2396E"
href="mailto:bion@microsoft.com" moz-do-not-send="true">
<bion@microsoft.com></a>; <a
class="x_moz-txt-link-abbreviated"
href="mailto:lib@lists.isocpp.org"
moz-do-not-send="true">
lib@lists.isocpp.org</a> <a
class="x_moz-txt-link-rfc2396E"
href="mailto:lib@lists.isocpp.org"
moz-do-not-send="true">
<lib@lists.isocpp.org></a>; Corentin <a
class="x_moz-txt-link-rfc2396E"
href="mailto:corentin.jabot@gmail.com"
moz-do-not-send="true">
<corentin.jabot@gmail.com></a><br>
<b>Cc:</b> C++ Library Evolution Working Group <a
class="x_moz-txt-link-rfc2396E"
href="mailto:lib-ext@lists.isocpp.org"
moz-do-not-send="true">
<lib-ext@lists.isocpp.org></a>; <a
class="x_moz-txt-link-abbreviated"
href="mailto:unicode@isocpp.open-std.org"
moz-do-not-send="true">
unicode@isocpp.open-std.org</a> <a
class="x_moz-txt-link-rfc2396E"
href="mailto:unicode@open-std.org"
moz-do-not-send="true">
<unicode@open-std.org></a><br>
<b>Subject:</b> Re: [isocpp-lib] [SG16-Unicode]
[isocpp-lib-ext] [time.duration.io] : Is stream insertion
behavior locale dependent when Period::type is micro?</font>
<div> </div>
</div>
<div style="background-color:#FFFFFF">
<div class="x_x_moz-cite-prefix">On 11/6/19 4:30 PM, Billy
O'Neal (VC LIBS) wrote:<br>
</div>
<blockquote type="cite">
<meta name="Generator" content="Microsoft Word 15
(filtered medium)">
<style>
<!--
@font-face
        {font-family:"Cambria Math"}
@font-face
        {font-family:"Yu Gothic"}
@font-face
        {font-family:Calibri}
p.x_x_MsoNormal, li.x_x_MsoNormal, div.x_x_MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif}
a:link, span.x_x_MsoHyperlink
        {color:blue;
        text-decoration:underline}
@page WordSection1
        {margin:1.0in 1.0in 1.0in 1.0in}
-->
</style>
<div class="x_x_WordSection1">
<p class="x_x_MsoNormal" style="margin-bottom:12.0pt">>
Please read the wording again. Note that it says that,
if those conditions are true, then the result is
unspecified. </p>
<p class="x_x_MsoNormal">If “the wording” means the P/R
of <a
href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcplusplus.github.io%2FLWG%2Fissue3314&data=02%7C01%7Cbion%40microsoft.com%7C74f197e07e854e96a8a708d762e027b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086587197316817&sdata=7Ay4MBsgFceIPx7HV2S1JNb9lMEmtRHK%2FMHGFe15enI%3D&reserved=0"
originalsrc="https://cplusplus.github.io/LWG/issue3314"
shash="AbFMb2+ZQlcYe7+JwqNB7NuqYbqXSNe2tUEbJXfGwvjb3ipjEpnMbRFEyTKZOZI4PLi9Cm/P+atasGv5rA8VtgiHQq0NCYKhtU4g4eflERerHcCh9/e1eDIKGG9EUUmCVWgeyxY2FwLBtNCUVYBjWSmFvWY4ONWn1CQRqhvjZaA="
moz-do-not-send="true">
https://cplusplus.github.io/LWG/issue3314</a>, 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.</p>
</div>
</blockquote>
<p>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.<br>
</p>
<p>I think it is important to say something here.
Otherwise, one could claim that the terminal failing to
display
<tt>"μs"</tt> because it is configured for an incompatible
encoding is non-conforming. Well, to the extent that the
standard addresses such devices.<br>
</p>
<p>Tom.<br>
</p>
<blockquote type="cite">
<div class="x_x_WordSection1">
<p class="x_x_MsoNormal"> </p>
<p class="x_x_MsoNormal">Corentin’s P/R below seems to
not have this concern.</p>
<p class="x_x_MsoNormal"> </p>
<p class="x_x_MsoNormal">Billy3</p>
<p class="x_x_MsoNormal"> </p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_x_divRplyFwdMsg" dir="ltr"><font
style="font-size:11pt" color="#000000" face="Calibri,
sans-serif"><b>From:</b> Lib
<a class="x_x_moz-txt-link-rfc2396E"
href="mailto:lib-bounces@lists.isocpp.org"
moz-do-not-send="true"><lib-bounces@lists.isocpp.org></a>
on behalf of Tom Honermann via Lib
<a class="x_x_moz-txt-link-rfc2396E"
href="mailto:lib@lists.isocpp.org"
moz-do-not-send="true"><lib@lists.isocpp.org></a><br>
<b>Sent:</b> Wednesday, November 6, 2019 1:12:48 PM<br>
<b>To:</b> Corentin <a
class="x_x_moz-txt-link-rfc2396E"
href="mailto:corentin.jabot@gmail.com"
moz-do-not-send="true">
<corentin.jabot@gmail.com></a><br>
<b>Cc:</b> Tom Honermann <a
class="x_x_moz-txt-link-rfc2396E"
href="mailto:tom@honermann.net"
moz-do-not-send="true">
<tom@honermann.net></a>; C++ Library Evolution
Working Group <a class="x_x_moz-txt-link-rfc2396E"
href="mailto:lib-ext@lists.isocpp.org"
moz-do-not-send="true">
<lib-ext@lists.isocpp.org></a>; Library
Working Group <a class="x_x_moz-txt-link-rfc2396E"
href="mailto:lib@lists.isocpp.org"
moz-do-not-send="true">
<lib@lists.isocpp.org></a>; <a
class="x_x_moz-txt-link-abbreviated"
href="mailto:unicode@isocpp.open-std.org"
moz-do-not-send="true">
unicode@isocpp.open-std.org</a> <a
class="x_x_moz-txt-link-rfc2396E"
href="mailto:unicode@open-std.org"
moz-do-not-send="true">
<unicode@open-std.org></a><br>
<b>Subject:</b> Re: [isocpp-lib] [SG16-Unicode]
[isocpp-lib-ext] [time.duration.io] : Is stream
insertion behavior locale dependent when Period::type
is micro?</font>
<div> </div>
</div>
<div dir="auto">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.
<div><br>
</div>
<div>Please read the wording again. Note that it says
that, if those conditions are true, then the result is
unspecified. <br>
<br>
<div id="x_x_x_AppleMailSignature" dir="ltr">Tom.</div>
<div dir="ltr"><br>
On Nov 6, 2019, at 12:07 PM, Corentin <<a
href="mailto:corentin.jabot@gmail.com"
moz-do-not-send="true">corentin.jabot@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<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="x_x_x_gmail_quote">
<div dir="ltr" class="x_x_x_gmail_attr">On Wed,
6 Nov 2019 at 04:51, Tom Honermann <<a
href="mailto:tom@honermann.net"
moz-do-not-send="true">tom@honermann.net</a>>
wrote:<br>
</div>
<blockquote class="x_x_x_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" moz-do-not-send="true">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" moz-do-not-send="true"><lib-ext@lists.isocpp.org></a> wrote:
</pre>
<blockquote type="cite">
<pre>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".</pre>
</blockquote>
</blockquote>
<br>
<div>Howard and I discussed the wording I
proposed today and we're now on the same
page with regard to the intent.<br>
</div>
<div><br>
</div>
<div>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).
<a
href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2Fp1859r0&data=02%7C01%7Cbion%40microsoft.com%7C74f197e07e854e96a8a708d762e027b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086587197316817&sdata=fRQkAXY8N4iGfVAcggrHXWcGfGZYnLTcKbn4EvQmh1E%3D&reserved=0"
originalsrc="http://wg21.link/p1859r0"
shash="CqnxvDYTc2k60TrDy4lWAi0LOVgE5xF+2aSxwkDN3VfYEa6FTfVPPZfSvIzmW1Z/4c0yfQSSTggEZwDfh5pnvjguOaeaFasuGej5i9AAXAIwYl2+3AUxhSCVtF0twaQbo01sZOen8eVvMgFC2EI3Al0Pv98XnTQ917Re8SrYACg="
target="_blank" moz-do-not-send="true">
P1859R0</a> 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.<br>
</div>
<div><br>
</div>
<div>Tom.<br>
</div>
<div><br>
</div>
<blockquote type="cite">
<blockquote type="cite">
<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" moz-do-not-send="true"><lib-ext@lists.isocpp.org></a> wrote:
A new LWG issue was filed for this question today:
- <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcplusplus.github.io%2FLWG%2Fissue3314&data=02%7C01%7Cbion%40microsoft.com%7C74f197e07e854e96a8a708d762e027b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086587197326768&sdata=EyplItoVn6mHk6%2BYsoWYfLuLKpfXFIVXR75m94jkUd0%3D&reserved=0" originalsrc="https://cplusplus.github.io/LWG/issue3314" shash="d1UbB+zTkIXADZjZXM/Cdq4DWZib3xc3IvtDA30d/fUok6o45jV70mTmNgQZEuGF2mYw1W3lpWtGXOb7Uuy4F0bHD8Zf1Vt7YAQzncCplQVLj2fxqZ9Gt19XRKdm8xsTPI0509rv5X1yWgzYNIMgzuhyrQDxkcblRC3GJjA6nhY=" target="_blank" moz-do-not-send="true">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="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftime.duration.io&data=02%7C01%7Cbion%40microsoft.com%7C74f197e07e854e96a8a708d762e027b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086587197326768&sdata=ZqgUK0G5nT3PIvt0z2JLkuCoQq%2Fj2rkQJguq1Yi5J08%3D&reserved=0" originalsrc="http://time.duration.io" shash="S4VQUzXFpQH9OtedR21Qawl0eAR89hJrN57jahrC/qEUCL6ya5RRKpo/wNfhfOB/ptxbdT9kwaNAQNFp2hQYRiDNcRh1h+O0UJsZIBZsYGRxoCq4gr9iiS352dOIWcHz0of7xsruREAeYnnRJVm+WAJiAqdCSjMGINJGJZu/ZnY=" target="_blank" moz-do-not-send="true">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 "us" is used instead of "μs".
</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't checked.
Tom.
</pre>
</blockquote>
<pre>_______________________________________________
Lib-Ext mailing list
<a href="mailto:Lib-Ext@lists.isocpp.org" target="_blank" moz-do-not-send="true">Lib-Ext@lists.isocpp.org</a>
Subscription: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&data=02%7C01%7Cbion%40microsoft.com%7C74f197e07e854e96a8a708d762e027b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086587197336730&sdata=KUn3PjJ0%2FhPiFTFa%2BCYhidHySoo7RmqWAFur1lJmDM4%3D&reserved=0" originalsrc="https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext" shash="OYJgaFn6gsUIPO6h4RFFL1qloczaQjEqaJY43LAH3gvW5eCfBjJ4cPxKFCNRftE0vYzFFxarmsiVisYxPCeS212ioss45jw7uvyjBcw5e7dk40GLzPDTfNbQKbbVAG3l8gNZUfU7dFc/gD+ploLVzYkFoaVPFyertGsgy2iQ9PM=" target="_blank" moz-do-not-send="true">https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext</a>
Link to this post: <a href="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%7C74f197e07e854e96a8a708d762e027b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086587197336730&sdata=INf%2BwIZDoM7tAbfb46SzNRxIk7o%2Fx1BeHeX%2BQETACwE%3D&reserved=0" originalsrc="http://lists.isocpp.org/lib-ext/2019/11/13309.php" shash="hXQ/S/bxEOY73miYpNBy5S+La/BCgP55pHioHNad5dgL2zkgmCTFSffgsjDxWvlzCQhBDc+nbsa8eI6dSmuHcIcOG1PdpISjcJ1YJUpd28YyJjIRWU+p9g+VHgsKbta7RBPiLXztMWAbzKH2Y8MwibPpfhUXkyCueVBfPTKWuWQ=" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">Lib-Ext@lists.isocpp.org</a>
Subscription: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Flib-ext&data=02%7C01%7Cbion%40microsoft.com%7C74f197e07e854e96a8a708d762e027b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086587197346685&sdata=aV2v1RPhQUAUDdiWggWhOKWRBHbBA6yRvF7h65gksqw%3D&reserved=0" originalsrc="https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext" shash="lQL4I3NECwhuqSdyHy4djIqqBdr+l3ahUH66nImuPVn/EwCv4BAXokltkJsR+ShtKXDXht5FPX+74BMc6NWVk9Sn6w6FrfGP4pHVR8Pi+5uwul6ZnJA2879W+DYVp7IDqr8k63qcYuw0dr5hKk3hhnSwsz4p+EU6cE2U0hzUc/M=" target="_blank" moz-do-not-send="true">https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext</a>
Link to this post: <a href="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%7C74f197e07e854e96a8a708d762e027b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086587197346685&sdata=Q7ssk2EUlVVMtDO9InNh1T1Mpi3SC3bjApHqlBs8KZg%3D&reserved=0" originalsrc="http://lists.isocpp.org/lib-ext/2019/11/13325.php" shash="Xid5vPBDNTyOeKmLMTKGyfzYlC3d2+eEhi5TwIDFmXVQ858sszaC5S8StYQ3uYye9arilbUaC5ijVZhTedJGuByaXBfS0H0FhqIGovkdXYaQIqSQZSugQCKp7jtvxMXTfd1LkO6vYXvECmTZTg+2bDthJNQzqj8El8z5r55+1mY=" target="_blank" moz-do-not-send="true">http://lists.isocpp.org/lib-ext/2019/11/13325.php</a>
</pre>
</blockquote>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
SG16 Unicode mailing list
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank" moz-do-not-send="true">Unicode@isocpp.open-std.org</a>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Funicode&data=02%7C01%7Cbion%40microsoft.com%7C74f197e07e854e96a8a708d762e027b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086587197356642&sdata=ldcvN7dm7G%2BRwnxOvfqJgm5d6hVw5jHp%2BFai51CBsjw%3D&reserved=0" originalsrc="http://www.open-std.org/mailman/listinfo/unicode" shash="QaJ5isVO69SWrNIDhfTjT97Cgtfvwg4Dc0NHhKttwaUXabWYYmipnjkpxHNzjJV+GmpGW2aihNqpL9LbFl+D0hLrPXeJDI/C8Xt55cSvYuhGDXkOUWbwFEZ6OkdJWx12tJA5zaISaZa8tWDYIX3Z3m4IgIAUvzQxOFPC1jHOQmA=" target="_blank" moz-do-not-send="true">http://www.open-std.org/mailman/listinfo/unicode</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>