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

[Shawn Erickson]

"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."

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.

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).

I see no good reason to muddle with the view aspects of String system (e.g.
UTFXxView).

-Shawn

On Tue, Feb 16, 2016 at 3:24 PM Guillaume Lessard via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160217/22a9d7d3/attachment.html>