<div dir="ltr">"<span><span style="font-size:13px">In the current proposal (and the current state of String), data goes into a String via one of its initializers.</span><br style="font-size:13px"><span style="font-size:13px">Data comes out of a String via one of the view types. It's fairly straightforward."</span></span><div><br></div><div>I agree. This proposal seems in good alignment with current String model which I think is actually a good model. I believe this proposal exposes a reasonable API to allow for – what I consider to be – a need capability in the base String API.</div><div><br></div><div>In summary adding String initializers that accept code point collections is useful and they can be designed such that you always get a valid String (e.g. with potential corrective action) or no String (failable initializer).</div><div><br></div><div>I see no good reason to muddle with the view aspects of String system (e.g. UTFXxView).</div><div><br></div><div>-Shawn<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 16, 2016 at 3:24 PM Guillaume Lessard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 16 févr. 2016, at 13:31, Patrick Gili <<a href="mailto:gili.patrick.r@gili-labs.com" target="_blank">gili.patrick.r@gili-labs.com</a>> wrote:<br>
><br>
> 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.<br>
<br>
Agreed.<br>
<br>
One alternative is to have initializers on UTF{8,16}View:<br>
<br>
String.UTF16View.init<Input: CollectionType where Input.Generator.Element == UTF16.CodeUnit>(input: Input)<br>
String.UTF8View.init<Input: CollectionType where Input.Generator.Element == UTF8.CodeUnit>(input: Input)<br>
<br>
There would probably be repairing and failable versions. However, the String initializers from UTF8View and UTF16View are failable themselves:<br>
<br>
String.init?(_ utf8: String.UTF8View)<br>
String.init?(_ utf16: String.UTF16View)<br>
<br>
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.<br>
<br>
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?<br>
<br>
<br>
In the current proposal (and the current state of String), data goes into a String via one of its initializers.<br>
Data comes out of a String via one of the view types. It's fairly straightforward.<br>
<br>
Guillaume Lessard<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>