[Review] SE-0035 Limiting inout capture to @noescape contexts


(Chris Lattner) #1

Hello Swift community,

The review of "Limiting inout capture to @noescape contexts" begins now and runs through February 19th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0035-limit-inout-capture.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
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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


(Joseph Lord) #2

+1

Rare case with complicated semantics. I approve of changing it to compile time error.

Gave the proposal a quick read and gave it a quick thought.

Joseph

···

Sent from my phone

On 17 Feb 2016, at 01:30, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "Limiting inout capture to @noescape


(Howard Lovatt) #3

+1 from me. I have been caught out :frowning:

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:

https://github.com/apple/swift-evolution/blob/master/proposals/0035-limit-inout-capture.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
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

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Shawn Erickson) #4

* What is your evaluation of the proposal?

+1. It makes an surprising edge case no longer surprising and favors being
explicit about it when needed.

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

Yes, the edge case has surprised folks and I could see my own code
mistakenly running across this (hasn't yet).

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

Yes I believe so.

* 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 missed the discussion but fully read and understood the proposal.


(Patrick Gili) #5

Hello Swift community,

The review of "Limiting inout capture to @noescape contexts" begins now and runs through February 19th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0035-limit-inout-capture.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
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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Lily Ballard) #6

  * 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?

A quick reading.

-Kevin Ballard

···

On Tue, Feb 16, 2016, at 05:30 PM, Chris Lattner wrote:


(Trent Nadeau) #7

- 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 :frowning:

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:

https://github.com/apple/swift-evolution/blob/master/proposals/0035-limit-inout-capture.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
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

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(TJ Usiyan) #8

+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?

A quick reading.

-Kevin Ballard
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution