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
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
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
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
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
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?
Looks good to me, especially if it eliminates a use case that simply doesn't work anymore.
* 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 don't think this applies, but I have never used this use case when employing closures in any other language I have used.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick read.
···
On Feb 16, 2016, at 8:30 PM, Chris Lattner <clattner@apple.com> wrote:
More information about the Swift evolution process is available at
+1. Seems like a good idea. Shadow copies of inout parameters are confusing.
* Is the problem being addressed significant enough to warrant a change to Swift?
Yes, it's a surprising edge case that can be hard to understand if you don't know what's going on.
* Does this proposal fit well with the feel and direction of Swift?
I think it's fairly neutral.
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
The only language that comes to mind that might have a similar situation is C++ with pass-by-ref parameters and C++11 lambdas, and I'm not quite sure how those interact. I assume that if you capture the parameter by-ref in the lambda, it'll capture the original reference, but in that case it would not be safe to have the lambda out-live the reference (i.e. there'd be no shadow copy made). But I've not actually researched this topic.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A quick reading.
-Kevin Ballard
···
On Tue, Feb 16, 2016, at 05:30 PM, Chris Lattner wrote:
- What is your evaluation of the proposal?
- +1. This seems like a reasonable way to prevent an existing
problematic behavior in Swift.
- Is the problem being addressed significant enough to warrant a change
to Swift?
- Yes. If the problem is enough to make it into multiple foot-gun
lists, then I think it's significant enough.
- 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?
- N/A
- How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
- I followed the swift-evolution thread and read the proposal.
···
On Tue, Feb 16, 2016 at 9:56 PM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote:
+1 from me. I have been caught out :(
I would go further and make all captured variables read only unless marked
by inout, i.e.:
func example(inout x: Int) {
escape { _ = x } // OK, immutable capture
noEscape { _ = x } // OK, immutable capture
noEscape {[inout x] in _ = x } // OK, closure is @noescape
escape {[inout x] in _ = x } // error: closure cannot implicitly
capture an inout parameter unless @noescape
}
Which would make closures consistent with functions.
Even though I would go further it is still a +1 for me for this proposal
since it is a step in the right direction.
-- Howard.
On 17 February 2016 at 12:30, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
Hello Swift community,
The review of "Limiting inout capture to @noescape contexts" begins now
and runs through February 19th. The proposal is available here:
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
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
+1 from me. The "shadow copy" behavior was a tricky problem to explain.
···
On Thu, Feb 18, 2016 at 5:09 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote:
On Tue, Feb 16, 2016, at 05:30 PM, Chris Lattner wrote:
> * What is your evaluation of the proposal?
+1. Seems like a good idea. Shadow copies of inout parameters are
confusing.
> * Is the problem being addressed significant enough to warrant a
change to Swift?
Yes, it's a surprising edge case that can be hard to understand if you
don't know what's going on.
> * Does this proposal fit well with the feel and direction of Swift?
I think it's fairly neutral.
> * If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
The only language that comes to mind that might have a similar situation
is C++ with pass-by-ref parameters and C++11 lambdas, and I'm not quite
sure how those interact. I assume that if you capture the parameter by-ref
in the lambda, it'll capture the original reference, but in that case it
would not be safe to have the lambda out-live the reference (i.e. there'd
be no shadow copy made). But I've not actually researched this topic.
> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?