<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style=""><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">&gt;</span><span style="display: inline !important; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">IMO,
 this is the wrong way to think about stability w.r.t Unicode.&nbsp; The changes that happen to Unicode are bug fixes.&nbsp; If they change the results users get when they use a certain API, it's a fix, not a regression.</span></div>
<div style=""><span style="display: inline !important;"><br>
</span></div>
<div style=""><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I agree that it isn't a regression. Whether it is a fix or not has nothing to do with whether it is a breaking change; it's breaking if anyone
 relies on the behavior that is broken. We have customers that are angry with us because we fixed printf to print doubles correctly. And we had to ship a mode for those customers to make printf be broken again.</span></div>
<div style=""><br>
</div>
<div style=""><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">&gt;</span><span style="display: inline !important; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">&gt;&gt;</span><span style="margin: 0px; display: inline; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">It
 is important to remember that width estimation is orthogonal to memory safety; format_to_n() is there to give you the memory safety part, and that will never be impacted by the width estimation piece.</span></div>
<div style=""><span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">&gt;&gt;</span><span style="display: inline !important; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I
 agree, but the same is true of sprintf vs. snprintf.</span></div>
<div style=""><span style="display: inline !important; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">&gt;That sounds right to me, but I don't get the implication.&nbsp; Why did you bring it up?</span><br>
</div>
<div style=""><span style="display: inline !important;"><br>
</span></div>
<div style=""><span style="display: inline !important; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">The implication is that if the customers of format/format_to/format_to_n are anything like the customers of sprintf/snprintf,
 there will be users who call the not sized interface expecting the format string to make it safe.</span></div>
<div style=""><span style="display: inline !important; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></div>
<div style=""><span style="display: inline !important; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Billy3</span></div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Zach Laine &lt;whatwasthataddress@gmail.com&gt;<br>
<b>Sent:</b> Wednesday, November 13, 2019 04:19 PM<br>
<b>To:</b> Billy O'Neal (VC LIBS) &lt;bion@microsoft.com&gt;<br>
<b>Cc:</b> Library Working Group &lt;lib@lists.isocpp.org&gt;; Kirk Shoop &lt;kirkshoop@fb.com&gt;; lib-ext@lists.isocpp.org &lt;lib-ext@lists.isocpp.org&gt;; Titus Winters &lt;titus@google.com&gt;; Victor Zverovich &lt;victor.zverovich@gmail.com&gt;; Corentin &lt;corentin.jabot@gmail.com&gt;;
 Tom Honermann &lt;tom@honermann.net&gt;; SG16 &lt;unicode@open-std.org&gt;<br>
<b>Subject:</b> Re: [isocpp-lib] [isocpp-lib-ext] The &quot;Let's Stop Ascribing Meaning to Code Points&quot; blog post</font>
<div>&nbsp;</div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">On Wed, Nov 13, 2019 at 1:28 PM Billy O'Neal (VC LIBS) &lt;<a href="mailto:bion@microsoft.com">bion@microsoft.com</a>&gt; wrote:<br>
</div>
<div class="x_gmail_quote">
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
&gt;<span style="color:rgb(32,31,30); font-size:15px; background-color:rgb(255,255,255); display:inline">Will you be hesitant&nbsp;to update the reference to the grapheme breaking algorithm if it changes in future Unicode standards as well?</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Yes. There's a reason why, for example, Java doesn't follow Unicode's rules in its regex implementation, because it would be a breaking change to do that.</div>
</div>
</blockquote>
<div><br>
</div>
<div>IMO, this is the wrong way to think about stability w.r.t Unicode.&nbsp; The changes that happen to Unicode are bug fixes.&nbsp; If they change the results users get when they use a certain API, it's a fix, not a regression.&nbsp; Adding an 8-width (or whatever it turns
 out to be) entry in the table for U&#43;FDFD in a later standard falls into that category.</div>
<div>&nbsp;</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
&gt;<span style="color:rgb(32,31,30); font-size:15px; background-color:rgb(255,255,255); display:inline">It is important to remember that width estimation is orthogonal to memory safety; format_to_n() is there to give you the memory safety part, and that will
 never be impacted by the width estimation piece.</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
I agree, but the same is true of sprintf vs. snprintf.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Billy3</div>
</div>
</blockquote>
<div><br>
</div>
<div>That sounds right to me, but I don't get the implication.&nbsp; Why did you bring it up?</div>
<div><br>
</div>
<div>Zach</div>
<div><br>
</div>
</div>
</div>
</div>
</body>
</html>