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

[Trent Nadeau]

   - 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 at 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 at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160216/3cd212b1/attachment.html>