# Swift string handling

**URL:** https://discourse.julialang.org/t/swift-string-handling/10622
**Category:** Offtopic
**Created:** [April 30, 2018, 12:31pm UTC](https://discourse.julialang.org/t/swift-string-handling/10622 "2018-04-30T12:31:10Z")
**Posts on this page:** 1
**Showing post:** 5

<div class="post-metadata">

### Author: ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [April 30, 2018, 4:42pm UTC](https://discourse.julialang.org/t/swift-string-handling/10622/5 "2018-04-30T16:42:07Z")

</div>

> [@Swift for Tensorflow rationale](https://discourse.julialang.org/t/swift-for-tensorflow-rationale/10563/13):
>
> we all know that you prefer a different string design, but your endless refrain that disagreeing with you equates with a second-class design is tiresome

I’ve always pointed out concrete issues with the string design in Julia, it’s not a matter of disagreeing or not with me, it’s about objective facts. The number of bugs that I fixed in the string handling code in the past, and the bugs that have been around for years and are still being found (like not handling the last character of a string correctly if is wasn’t ASCII in a search), as well as the performance issues with strings in Julia, back in v0.3 before I learned about Julia, and now in master can be easily shown with benchmarking.  
The lack of validated string types goes against the strong recommendations of the Unicode organization, W3C, IETF, and other bodies, because of many known security issues.

> [@Swift for Tensorflow rationale](https://discourse.julialang.org/t/swift-for-tensorflow-rationale/10563/13):
>
> Swift’s String type reportedly uses a single variable-width encoding internally (UTF-16 last I checked, hence relatively inefficient for mostly-ASCII data), hence has an analogue of Julia’s nextind to increment string indices, while its Character type is actually a grapheme cluster (hence variable-width and relatively slow) analogous to Julia’s graphemes iterator over substrings. It also exposes iterators over code points and code units, but as far as I can tell these don’t support random access (only forwards and backwards iteration).

Have you actually looked at the documentation and source code for Swift string support?

They keep track (like I do in Strs.jl) of properties of strings, like whether it is just ASCII, etc.  
Given that most all text in the world can be represented using just the 16-bit BMP of Unicode, the Swift code has fast paths that optimize that case (so no slow “nextind” like issues).  
You can perform all sorts of indexing operations on `utf8`, `utf16`, `unicodeScalar` and other views of strings, random access _is_ possible, not just iteration. Swift uses a String.Index type (a similar idea was discussed for Julia at one point, I believe), and you can even compare indices from different string types to see if they represent the same position in the string.

> [@Swift for Tensorflow rationale](https://discourse.julialang.org/t/swift-for-tensorflow-rationale/10563/13):
>
> Swift’s strings are mutable with copy-on-write semantics, whereas Julia uses IOBuffer for string building.

This works very intuitively, and performs very well.  
`IOBuffer`s can’t handle alternate string types, everything is geared towards data being forced to use UTF-8 encoding, and using them to build strings is rather clumsy, and people tend to write rather inefficient code instead, doing things like `str += "ing"`, which is efficient in both Swift and Python.

---

_[View the full topic](https://discourse.julialang.org/t/swift-string-handling/10622)._