<div><div><div>If we leave aside for a moment the nomenclature issue where everything in Foundation referring to a character is really referring to a Unicode scalar, Kevin’s example illustrates the whole problem in a nutshell, doesn’t it? In that example, we have a straightforward attempt to slice with a misaligned index. The totality of options here are:</div><div><br></div><div>* return nil, an option the rejection of which is the premise of your proposal</div><div>* return a partial character (i.e., \u{301}), an option which we haven’t yet talked about in this thread–seems like this could have simpler semantics, potentially yields garbage if the index is garbage but in the case of Kevin’s example actually behaves as the user might expect</div></div><div>* return a whole character after “rounding down”–difficult semantics to define and explain, always results in a whole character but in the case of Kevin’s example gives an unexpected answer</div><div>* returns a whole character after “rounding up”–difficult semantics to define and explain, always results in a whole character but when the index is misaligned would result in a character or range of characters in which the index is not found</div><div>* trap–simple semantics, never returns garbage, obvious disadvantage that execution will not proceed</div><div><br></div><div>No clearly perfect answer here. However, _if_ we hew strictly to the stated premise of your proposal that failable APIs are awkward enough to justify a change, and moreover that the awkwardness is truly “needless” because of the rarity of misaligned index usage, then at face value trapping should be a perfectly acceptable solution.</div><div><br></div><div>That Kevin’s example raises the specter of trapping being a realistic occurrence in currently working code actually suggests a challenge to your stated premise. If we accept that this challenge is a substantial one, then it’s not clear to me that abandoning failable APIs should be ruled out from the outset.</div><div><br></div><div>However, if this desire to remove failable APIs remains strong then I wonder if the undiscussed second option above is worth at least some consideration.</div></div><div><div><br></div><div><div><br><div class="gmail_quote"><div>On Wed, Jun 14, 2017 at 08:49 Dave Abrahams &lt;<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; On Jun 13, 2017, at 6:16 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; I’m coming to this conversation rather late, so forgive the naive question:<br>
&gt;<br>
&gt; Your proposal claims that current code with failable APIs is needlessly awkward and that most code only interchanges indices that are known to succeed. So, why is it not simply a precondition of string slicing that the index be correctly aligned? It seems like this would simplify the behavior greatly.<br>
<br>
Well, consider the case raised by Kevin Ballard if nothing else: that code would start trapping.<br>
<br>
-Dave</blockquote></div></div></div></div>