[swift-evolution] [Review] SE-0027 Expose code unit initializers on String
dabrahams at apple.com
Mon Feb 15 10:48:32 CST 2016
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
> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> 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:
> 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
First, in the presentation, there are several things that make it hard
1. The "decode" function signature is so wide that it can't be read
without scrolling at
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
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:
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
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
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?
> 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
> 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.
More information about the swift-evolution