<div style="white-space:pre-wrap">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.)<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 16, 2016 at 02:00 Michael Savich <<a href="mailto:savichmichael@icloud.com">savichmichael@icloud.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
Sent from my iPad<br>
<br>
> On Aug 15, 2016, at 2:50 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
> The ship has sailed on that decision, I'd imagine.<br>
><br>
> 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.<br>
</blockquote></div>