Swift supports arbitrary Unicode for identifier names, so Unicode would have to be supported even for debugging strings.
On Mon, Aug 15, 2016 at 12:54 Michael Savich <[email protected]> wrote: > Well, the thing I've been thinking is that InternalString doesn't have to > be just for learning. There is value in distinguishing between whether a > String is for UI or just for code. I get that Swift wants to be Unicode > friendly, but I think that only really benefits when dealing with UI and > possibly APIs. > > I think String wears too many hats-- the best way forward is to split it > up. As it is String is a bit like an NSImage, and I'm not sure that is a > good thing for a basic type. > > Sent from my iPhone > > On Aug 15, 2016, at 1:42 PM, Xiaodi Wu <[email protected]> wrote: > > On Sun, Aug 14, 2016 at 5:41 PM, Michael Savich via swift-evolution < > [email protected]> wrote: > >> Back in Swift 1.0, subscripting a String was easy, you could just use >> subscripting in a very Python like way. But now, things are a bit more >> complicated. I recognize why we need syntax like >> str.startIndex.advancedBy(x) but it has its downsides. Namely, it makes >> things hard on beginners. If one of Swift's goals is to make it a great >> first language, this syntax fights that. Imagine having to explain Unicode >> and character size to an 8 year old. This is doubly problematic because >> String manipulation is one of the first things new coders might want to do. >> >> What about having an InternalString subclass that only supports one >> encoding, allowing it to be subscripted with Ints? The idea is that an >> InternalString is for Strings that are more or less hard coded into the >> app. Dictionary keys, enum raw values, that kind of stuff. This also has >> the added benefit of forcing the programmer to think about what the String >> is being used for. Is it user facing? Or is it just for internal use? And >> of course, it makes code dealing with String manipulation much more concise >> and readable. >> >> It follows that something like this would need to be entered as a literal >> to make it as easy as using String. One way would be to make all String >> literals InternalStrings, but that sounds far too drastic. Maybe appending >> an exclamation point like "this"! Or even just wrapping the whole thing in >> exclamation marks like !"this"! Of course, we could go old school and write >> it like @"this" …That last one is a joke. >> >> I'll be the first to admit I'm way in over my head here, so I'm very open >> to suggestions and criticism. Thanks! >> > > I can sympathize, but this is tricky. > > Fundamentally, if it's going to be a learning and teaching issue, then > this "easy" string should be the default. That is to say, if I write `var a > = "Hello, world!"`, then `a` should be inferred to be of type > InternalString or EasyString, whatever you want to call it. > > But, we also want Swift to support Unicode by default, and we want that > support to do things The Right Way(TM) by default. In other words, a user > should not have to reach for a special type in order to handle arbitrary > strings correctly, and I should be able to reassign `a = "你好"` and have > things work as expected. So, we also can't have the "easy" string type be > the default... > > I can't think of a way to square that circle. > > >> >> Sent from my iPad >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
