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, 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?
* 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 you 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
Re-reading the proposal, I just want to clarify that all the members of
UnicodeScalarView are read-only. You can't mutate a UnicodeScalarView,
all you can do is read data from it. More specifically, the properties
`startIndex`, `endIndex`, `isEmpty` and the subscript operator should
all be treated as if they specified `{ get }`.
-Kevin Ballard
···
On Wed, Jan 6, 2016, at 04:58 PM, Douglas Gregor via swift-evolution wrote:
Hello Swift community,
The review of SE-0010 "Add StaticString.UnicodeScalarView" begins now
and runs through Friday, January 8th. 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, 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? * 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 you 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
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, 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 think the proposal provides added value, as long as StaticString.UnicodeScalarView is immutable.
* 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?
Yes.
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I do not.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A thorough reading with the intent of understanding the problem, the alternatives for solving that problem, and consideration as to whether the proposed solution is the best alternative.
···
On Jan 6, 2016, at 7:58 PM, Douglas Gregor <dgregor@apple.com> wrote:
More information about the Swift evolution process is available at
* Is the problem being addressed significant enough to warrant a change
to Swift?
Yes. (To be clear, I think it's important, but not urgent.)
* Does this proposal fit well with the feel and direction of Swift?
Yes; it seems consistent with other String APIs.
* If you have you used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
N/A; Swift's String types put all others to shame ;-)
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
I read through the proposal quickly. I mostly looked at the proposed API,
and in comparison to the existing String APIs, I feel this is a logical &
useful addition to the standard library.
Question: Why doesn't this proposal also include UTF8View and UTF16View?
Ah yes, I did intend for that to be immutable. It's actually technically
valid for it to be mutable, since mutating it would be identical to just
reassigning to the variable holding the StaticString with another
StaticString, but it's definitely supposed to be immutable.
-Kevin Ballard
···
On Thu, Jan 7, 2016, at 12:01 PM, Patrick Gili via swift-evolution wrote:
* What is your evaluation of the proposal?
I think the proposal provides added value, as long as
StaticString.UnicodeScalarView is immutable.
I've submitted a PR that updates the proposal to show that the API is
immutable.
-Kevin Ballard
···
On Wed, Jan 6, 2016, at 05:04 PM, Kevin Ballard wrote:
Re-reading the proposal, I just want to clarify that all the
members of UnicodeScalarView are read-only. You can't mutate a
UnicodeScalarView, all you can do is read data from it. More
specifically, the properties `startIndex`, `endIndex`, `isEmpty`
and the subscript operator should all be treated as if they
specified `{ get }`.
-Kevin Ballard
On Wed, Jan 6, 2016, at 04:58 PM, Douglas Gregor via swift- > evolution wrote:
Hello Swift community,
The review of SE-0010 "Add StaticString.UnicodeScalarView" begins now
and runs through Friday, January 8th. 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, 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? * 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 you 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
Mostly because those are extra work and I didn't see much benefit to
them. The point of this addition is simply to make it possible to slice
StaticStrings and get something useful. If you want to work with UTF-8
you can already use the utf8Start + byteSize properties (assuming the
StaticString isn't storing a single unicode scalar), and if you want to
work with UTF-16, you probably already want to be using String. Also,
even if we had a UTF8View and a UTF16View, you couldn't actually use
them to slice the StaticString since a StaticString must contain a valid
unicode sequence. They could have methods to translate from UTF8/UTF16
indices into UnicodeScalarView indices like String does, but ultimately,
it seems like a lot of work for something that nobody's actually going
to get around to using.
-Kevin Ballard
···
On Fri, Jan 8, 2016, at 09:56 PM, Jacob Bandes-Storch wrote:
Question: Why doesn't this proposal also include UTF8View and UTF16View?