2 ms·

In Swift you have access to the utf8 and utf16 views. For a string constructed from UTF8 the utf8 view is a view onto the underlying storage more or less. That

In Swift you have access to the utf8 and utf16 views. For a string constructed from UTF8 the utf8 view is a view onto the underlying storage more or less. That said the String API is getting some revisions in Swift 4 to make it both faster and easier to use without sacrificing correctness. Swift supports unicode in source code so its parser is unicode aware. I'm not sure there is a good case for parsing in a non-unicode-aware way. If you're working with strings as opaque data why are you even using a String type?

Manishearth 10y ago
Isn't the access to the views an iterator? > I'm not sure there is a good case for parsing in a non-unicode-aware way I'm not saying that you should parse in a non-unicode-aware way, I'm saying that most parsing code deals with ASCII delimeters, so grapheme clusters are a distraction (and will mess up parsing, since most formats do not consider EGCs. An HTML closing tag followed by an accent would totally break the parser otherwise). You rarely need to index, though. Basically, in parsing, you're looking for characters which themselves are single code points. So it doesn't matter. > If you're working with strings as opaque data Well, not entirely opaque :) But the String type is basically "here is a valid piece of UTF8 data", and you can pass that around. That's a distinct enough purpose to have a String type, even if you don't mess with its innards. IME the most used String APIs are those for interpolation, concatenation, and search, all of which don't need to be EGC aware (though search being EGC aware is sometimes a good thing). Slicing sometimes gets used in conjunction with the others.
hsivonen 10y ago
Is the memory representation of Swift strings now documented as something that programmers can rely on for performance characteristics? I read the Swift Book when Swift first came out and it bothered me a lot that the book didn't say what the memory representation of strings is. In contrast, Rust documentation is very clear about this stuff.
- Manishearth 10y ago
  It's a tagged union of utf8 and utf16 IIRC. I had to look at the stdlib source when I was trying to figure this out.

Manishearth 10y ago

Isn't the access to the views an iterator? > I'm not sure there is a good case for parsing in a non-unicode-aware way I'm not saying that you should parse in a non-unicode-aware way, I'm saying that most parsing code deals with ASCII delimeters, so grapheme clusters are a distraction (and will mess up parsing, since most formats do not consider EGCs. An HTML closing tag followed by an accent would totally break the parser otherwise). You rarely need to index, though. Basically, in parsing, you're looking for characters which themselves are single code points. So it doesn't matter. > If you're working with strings as opaque data Well, not entirely opaque :) But the String type is basically "here is a valid piece of UTF8 data", and you can pass that around. That's a distinct enough purpose to have a String type, even if you don't mess with its innards. IME the most used String APIs are those for interpolation, concatenation, and search, all of which don't need to be EGC aware (though search being EGC aware is sometimes a good thing). Slicing sometimes gets used in conjunction with the others.

hsivonen 10y ago

Is the memory representation of Swift strings now documented as something that programmers can rely on for performance characteristics? I read the Swift Book when Swift first came out and it bothered me a lot that the book didn't say what the memory representation of strings is. In contrast, Rust documentation is very clear about this stuff.

Manishearth 10y ago
It's a tagged union of utf8 and utf16 IIRC. I had to look at the stdlib source when I was trying to figure this out.