The utf16 property can already be subscripted with an Int, just as you desire, if you import Foundation. (See the code for corelibs-foundation for an intriguing discussion of why you must import Foundation at the moment.)
On Tue, Aug 16, 2016 at 02:00 Michael Savich <savichmich...@icloud.com> wrote: > What about adding a property to String called naiveCharacters (someone > come up with a better name) that can be subscripted with an Int a la Swift > 1.0, and if it leads to runtime errors at least the programmer was warned? > We could make this property an optional that is only non-nil if the String > was created using literal syntax. > > Of course there is the risk that tying arbitrary behavior to the literal > syntax might be too weird for a language feature, but it's an idea. > > Sent from my iPad > > > On Aug 15, 2016, at 2:50 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > The ship has sailed on that decision, I'd imagine. > > > > But in any case, debugging strings would still need to support Unicode > because file paths, etc., need to be Unicode-aware. IMO, you're right that > a clear distinction between UI and non-UI is useful, but that doesn't break > down into Unicode vs. ASCII, and it's not clear to me that strings used for > these two purposes need or should have distinct APIs. >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution