<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 25, 2017, at 3:26 PM, David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Ted, <div class=""><br class=""></div><div class="">It might have helped if instead of being called String and Character, they were named Text </div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>[1] <a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md#the-default-behavior-of-string" class="">https://github.com/apple/swift/blob/master/docs/StringManifesto.md#the-default-behavior-of-string</a></div><a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md#the-default-behavior-of-string" class=""></a><div>[2] <a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md#future-directions" class="">https://github.com/apple/swift/blob/master/docs/StringManifesto.md#future-directions</a></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">and ExtendedGraphemeCluster. </div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>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).</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><div class=""><div class=""><br class=""></div></div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div class="">Thats not to say that there aren’t features which would simplify/clarify algorithms working in this manner.</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 24, 2017, at 4:27 PM, Ted F.A. van Gaalen via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">ok, I understand, thank you<div class="">TedvG<br class=""><div style="" class=""><blockquote type="cite" class=""><div class="">On 25 Feb 2017, at 00:25, David Sweeris <<a href="mailto:davesweeris@mac.com" class="">davesweeris@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Feb 24, 2017, at 13:41, Ted F.A. van Gaalen <<a href="mailto:tedvgiosdev@gmail.com" class="">tedvgiosdev@gmail.com</a>> wrote:<br class=""><br class="">Hi David & Dave<br class=""><br class="">can you explain that in more detail?<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Wouldn’t that turn simple character access into a mutating function?<br class=""></blockquote></blockquote><br class="">assigning like s[11…14] = str is of course, yes.<br class="">only then - that is if the character array thus has been changed - <br class="">it has to update the string in storage, yes. <br class=""><br class="">but str = s[n..<m] doesn’t. mutate.<br class="">so you’d have to maintain keep (private) a isChanged: Bool or bit.<br class="">a checksum over the character array . <br class="">?<br class=""></blockquote><br class="">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.<br class=""><br class="">- Dave Sweeris </div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>