[swift-evolution] [swift-evolution-announce] [Review] SE-0027 Expose code unit initializers on String

[Guillaume Lessard]

> On 16 févr. 2016, at 13:31, Patrick Gili <gili.patrick.r at gili-labs.com> wrote:
> 
> Dave Abrahams echoed a cancern of mine though. The section discussing alternatives presents an alternative that might present a better solution to the problem. We should discuss this.

Agreed.

One alternative is to have initializers on UTF{8,16}View:

String.UTF16View.init<Input: CollectionType where Input.Generator.Element == UTF16.CodeUnit>(input: Input)
String.UTF8View.init<Input: CollectionType where Input.Generator.Element == UTF8.CodeUnit>(input: Input)

There would probably be repairing and failable versions. However, the String initializers from UTF8View and UTF16View are failable themselves:

String.init?(_ utf8: String.UTF8View)
String.init?(_ utf16: String.UTF16View)

Either we allow building incorrect instances of UTF{8,16}View, or their slices must be correct at all times and the String initializers can be made non-failable. Or we have to check for nil twice in the process. I don’t see how this would be more elegant.

The alternative specifically mentioned in 0027 is mutable forms of UTF{8,16}View; I’m not sure what the idea is here. Does applying a mutation to String.utf8 mutate the parent String?


In the current proposal (and the current state of String), data goes into a String via one of its initializers.
Data comes out of a String via one of the view types. It's fairly straightforward.

Guillaume Lessard