[swift-evolution] Strings in Swift 4

[Michael Ilseman]

> On Feb 25, 2017, at 3:26 PM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Ted, 
> 
> It might have helped if instead of being called String and Character, they were named Text

I would oppose taking a good name like “Text” and using it for Strings which are mostly for machine processing purposes, but can be human-presentable with explicit locale. A name like Text would a better fit for Strings bundled with locale etc. for the purpose of presentation to humans, which must always be in the context of some locale (even if a “default” system locale). Refer to the sections in the String manifesto[1][2]. Such a Text type is definitely out-of-scope for current discussion.

[1] https://github.com/apple/swift/blob/master/docs/StringManifesto.md#the-default-behavior-of-string
 <https://github.com/apple/swift/blob/master/docs/StringManifesto.md#the-default-behavior-of-string>[2] https://github.com/apple/swift/blob/master/docs/StringManifesto.md#future-directions

> and ExtendedGraphemeCluster. 
> 

What is expressed by Swift’s Character type is what the Unicode standard often refers to as a “user-perceived character”. Note that “character” by it self is not meaningful in Unicode (though it is often thrown about casually). In Swift, Character is an appropriate name here for the concept of a user-perceived character. If you want bytes, then you can use UInt8. If you want Unicode scalar values, you can use UnicodeScalar. If you want code units, you can use whatever that ends up looking (probably an associated type named CodeUnit that is bound to UInt8 or UInt16 depending on the encoding).


> They don’t really have the same behavior or functionality as string/characters in many other languages, especially older languages. This is because in many languages, strings are not just text but also random-accesss (possibly binary) data.
> 
> Thats not to say that there aren’t a ton of algorithms where you can use Text like a String, treat ExtendedGraphemeCluster like a character, and get unicode behavior without thinking about it.
> 
> But when it comes to random access and/or byte modification, you are better off working with something closer to a traditional (byte) string interface.
> 
> Trying to wedge random access and byte modification into the Swift String will simply complicate everything, slow down the algorithms which don’t need it, eat up more memory, as well as slow down bridging between Swift and Objective C code.
> 
> Hence me suggesting earlier working with Data, [UInt8], or [Character] within the context of your manipulation code, then converting to a Swift String at the end. Convert to the data format you need, then convert back.
> 
> Thats not to say that there aren’t features which would simplify/clarify algorithms working in this manner.
> 
> -DW
> 
>> On Feb 24, 2017, at 4:27 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> ok, I understand, thank you
>> TedvG
>>> On 25 Feb 2017, at 00:25, David Sweeris <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
>>> 
>>> 
>>>> On Feb 24, 2017, at 13:41, Ted F.A. van Gaalen <tedvgiosdev at gmail.com <mailto:tedvgiosdev at gmail.com>> wrote:
>>>> 
>>>> Hi David & Dave
>>>> 
>>>> can you explain that in more detail?
>>>>>> Wouldn’t that turn simple character access into a mutating function?
>>>> 
>>>> assigning like   s[11…14] = str  is of course, yes.
>>>> only then - that is if the character array thus has been changed - 
>>>> it has to update the string in storage, yes. 
>>>> 
>>>> but  str = s[n..<m]   doesn’t. mutate.
>>>> so you’d have to maintain keep (private) a isChanged: Bool or bit.
>>>> a checksum over the character array .  
>>>> ?
>>> 
>>> It mutates because the String has to instantiate the Array<Character> to which you're indexing into, if it doesn't already exist. It may not make any externally visible changes, but it's still a change.
>>> 
>>> - Dave Sweeris
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20170226/79c8529b/attachment.html>