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

Xiaodi Wu xiaodi.wu at gmail.com
Wed Jun 14 11:22:07 CDT 2017

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>

More information about the swift-evolution mailing list