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

[Dave Abrahams]

on Thu Feb 11 2016, Douglas Gregor <swift-evolution at swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0027 "Expose code unit initializers on String" begins
> now and runs through February 16, 2016. The proposal is available
> here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0027-string-from-code-units.md
> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at
> the top of the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0027-string-from-code-units.md
> Reply text
>
> Other replies
>  <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the
> direction of Swift. When writing your review, here are some questions
> you might want to answer in your review:
>
> What is your evaluation of the proposal?

I support the intent of the proposal but am -1 on the specific proposal
as offered.

First, in the presentation, there are several things that make it hard
to evaluate:

1. The "decode" function signature is so wide that it can't be read
   without scrolling at
   https://github.com/apple/swift-evolution/blob/master/proposals/0027-string-from-code-units.md

2. The proposal doesn't show any usage of the proposed APIs, so it
   is hard to understand what effect these APIs would have on real
   code.  There are some examples of uses in
   https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units
   but I have to dig for them.

3. The description of the “Detailed Design” doesn't show any examples
   either, so I have to imagine what “backporting the Swift 3.0 versions
   of the CString constructors, then making them generic over their
   input and codec” means.

Next, when I look at *uses* that I can find (in the tests), I don't find
them to be clear.

  String(validatingCodeUnits: result, as: UTF8.self)

What does “validatingCodeUnits” mean?  Clearly we're going to do some
checking.  Is there a repair?  Is the initializer failable?  

In this change, for example:
https://github.com/apple/swift/compare/master...zwaldowski:string-from-code-units#diff-d39ec2c4819c950aeef95f899f53b104R79
I find the old code much clearer than the new code (I'm not sure why
_decode starts with an underscore here; isn't it part of your proposed
public API?)

Lastly, I am very concerned about the “Alternatives Considered” section,
where, of one alternative, it says:

      This might be the better long-term solution from the perspective
      of API maintenance, but in the meantime this proposal has a fairly
      low impact.

We can't accept changes into the standard library “in the meantime,”
with the expectation that something more comprehensive will make them
obsolete.  Even though we've had migration tools, we never operated that
way in the past, and as we head toward API and ABI stability it is even
more true today.

> Is the problem being addressed significant enough to warrant a change
> to Swift?

Yes.

> Does this proposal fit well with the feel and direction of Swift?  

W.r.t. direction, the fact that we have a major String overhaul planned
means that tackling this one corner of the API is probably not entirely
appropriate.

> How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?

between quick reading and in-depth study.

-- 
-Dave