[swift-evolution] [Review] SE-0180: String Index Overhaul

[Dave Abrahams]

on Wed Jun 14 2017, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:

> 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:
>
> * return nil, an option the rejection of which is the premise of your
> proposal
> * 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
> * 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
> * 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
> * trap–simple semantics, never returns garbage, obvious disadvantage that
> execution will not proceed
>
> 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.
>
> 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.
>
> 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.

I think you're misunderstanding the motivation here.  It's not so much
that I want to remove failable APIs as that I want to reduce overall API
surface area.  The current index conversion APIs contribute 16
initializers and 16 methods to the overall size of the library.

-- 
-Dave