[swift-evolution] InternalString class for easy String manipulation

[Xiaodi Wu]

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 <savichmichael at icloud.com>
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 <xiaodi.wu at gmail.com> wrote:
>
> On Sun, Aug 14, 2016 at 5:41 PM, Michael Savich via swift-evolution <
> swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160815/9e30f682/attachment.html>