> On Feb 25, 2017, at 3:26 PM, David Waite via swift-evolution > <[email protected]> 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 >> <[email protected] <mailto:[email protected]>> wrote: >> >> ok, I understand, thank you >> TedvG >>> On 25 Feb 2017, at 00:25, David Sweeris <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On Feb 24, 2017, at 13:41, Ted F.A. van Gaalen <[email protected] >>>> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > 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
