The review of "SE-0130: Replace repeating Character and UnicodeScalar forms of String.init" begins now and runs through July 24. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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?
* 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?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
* Is the problem being addressed significant enough to warrant a change to Swift?
It's pretty minor but disproportionately annoying, so worth addressing.
* Does this proposal fit well with the feel and direction of Swift?
This I'm not sure on, partly because no alternatives are given. In particular I'm wondering whether this could be addressed instead by adding a string literal version of the initialiser, as this should I think giving the compiler an exact match to select instead?
It's tough to weigh in on which is better though, as I don't use this much at all; I do however have a couple of uses of the Character initialiser that I'd be very slightly inconvenienced by if they were removed, but hardly upset about. I just wanted to float that I believe this may be an alternative that hasn't been considered:
public init(repeating repeatedValue:StringLiteralType, count:Int) { … }
public mutating func append(_ other:StringLiteralType) { … }
But both alternatives are sufficiently Swift-y, and I'm not too bothered either way so long as the ambiguity is addressed.
···
On 22 Jul 2016, at 21:23, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
The new API is useful for initializing string by pattern.
But should not replace the old API.
The reason we need 'as' is there's no character literal, like 'a' , '\nnnn'
in other languages.
Haravikk via swift-evolution <swift-evolution@swift.org>于2016年7月23日
周六19:59写道：
···
On 22 Jul 2016, at 21:23, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
* What is your evaluation of the proposal?
I think I'm generally in favour (see later).
* Is the problem being addressed significant enough to warrant a change to
Swift?
It's pretty minor but disproportionately annoying, so worth addressing.
* Does this proposal fit well with the feel and direction of Swift?
This I'm not sure on, partly because no alternatives are given. In
particular I'm wondering whether this could be addressed instead by adding
a string literal version of the initialiser, as this should I think giving
the compiler an exact match to select instead?
It's tough to weigh in on which is better though, as I don't use this much
at all; I do however have a couple of uses of the Character initialiser
that I'd be very slightly inconvenienced by if they were removed, but
hardly upset about. I just wanted to float that I believe this may be an
alternative that hasn't been considered:
public init(repeating repeatedValue:StringLiteralType, count:Int) { … }
public mutating func append(_ other:StringLiteralType) { … }
But both alternatives are sufficiently Swift-y, and I'm not too bothered
either way so long as the ambiguity is addressed.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution