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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution