[swift-evolution] InternalString class for easy String manipulation

[Austin Zheng]

I just want to mention that the standard library team (or, more
specifically, Dave and Dmitri) is planning a rewrite of Swift's String
subsystem, in part to make it easier to work with strings in the "common
case". We may want to get their input, or wait until they've prepared a
proposal.

Best,
Austin

On Mon, Aug 15, 2016 at 10:58 AM, Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>>
>>>
>>
> _______________________________________________
> 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/c3e833b2/attachment.html>