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

[Xiaodi Wu]

On Wed, Jun 14, 2017 at 11:13 AM, Dave Abrahams <dabrahams at apple.com> wrote:

>
> 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.
>

Ah, and presumably, having only failable APIs once these different index
types are collapsed into one would be too cumbersome.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170614/316f5353/attachment.html>