<div dir="ltr">On Wed, Jun 14, 2017 at 11:13 AM, Dave Abrahams <span dir="ltr"><<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
on Wed Jun 14 2017, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br>
<br>
> If we leave aside for a moment the nomenclature issue where everything in<br>
> Foundation referring to a character is really referring to a Unicode<br>
> scalar, Kevin’s example illustrates the whole problem in a nutshell,<br>
> doesn’t it? In that example, we have a straightforward attempt to slice<br>
> with a misaligned index. The totality of options here are:<br>
><br>
> * return nil, an option the rejection of which is the premise of your<br>
> proposal<br>
> * return a partial character (i.e., \u{301}), an option which we haven’t<br>
> yet talked about in this thread–seems like this could have simpler<br>
> semantics, potentially yields garbage if the index is garbage but in the<br>
> case of Kevin’s example actually behaves as the user might expect<br>
> * return a whole character after “rounding down”–difficult semantics to<br>
> define and explain, always results in a whole character but in the case of<br>
> Kevin’s example gives an unexpected answer<br>
> * returns a whole character after “rounding up”–difficult semantics to<br>
> define and explain, always results in a whole character but when the index<br>
> is misaligned would result in a character or range of characters in which<br>
> the index is not found<br>
> * trap–simple semantics, never returns garbage, obvious disadvantage that<br>
> execution will not proceed<br>
><br>
> No clearly perfect answer here. However, _if_ we hew strictly to the stated<br>
> premise of your proposal that failable APIs are awkward enough to justify a<br>
> change, and moreover that the awkwardness is truly “needless” because of<br>
> the rarity of misaligned index usage, then at face value trapping should be<br>
> a perfectly acceptable solution.<br>
><br>
> That Kevin’s example raises the specter of trapping being a realistic<br>
> occurrence in currently working code actually suggests a challenge to your<br>
> stated premise. If we accept that this challenge is a substantial one, then<br>
> it’s not clear to me that abandoning failable APIs should be ruled out from<br>
> the outset.<br>
><br>
> However, if this desire to remove failable APIs remains strong then I<br>
> wonder if the undiscussed second option above is worth at least some<br>
> consideration.<br>
<br>
</div></div>I think you're misunderstanding the motivation here. It's not so much<br>
that I want to remove failable APIs as that I want to reduce overall API<br>
surface area. The current index conversion APIs contribute 16<br>
initializers and 16 methods to the overall size of the library.<br></blockquote><div><br></div><div>Ah, and presumably, having only failable APIs once these different index types are collapsed into one would be too cumbersome.</div></div></div></div>