On Wed, Jun 14, 2017 at 11:13 AM, Dave Abrahams <dabrah...@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution