[swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

[Andrew Bennett]

 * What is your evaluation of the proposal?
+1

I agree with others that there are opportunities to generalise this
proposal.

It would be pretty magical if it could be applied to escaping closures,
less magical if that's just adding a runtime assertion. It would also be
much more flexible if it could be used for multiple exclusive `if-else`
closures. However, I don't think this magic or flexibility is necessary to
make this proposal useful.

This proposal does add things you wouldn't be able to do otherwise, and
it's made clear to the user by the explicit pairing of @noescape and once.

--

It would be okay if (once) became @once, however I think this is only
useful if it was allowed on escaping closures. Adding compile-time
assurances to this is possible, but much more complicated (requiring strict
checks on storage, calling, passing).

I'm not sure if the added complexity of an escaping once is worth
considering until Swift concurrency (Swift 4?). I don't think the
guarantees would have any advantage for the compiler, and I don't think the
*currently* advantage to the user would be worth much more than a comment.

        * 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 used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
no
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
I have followed the thread, read the proposal, participated in the the
discussion.


On Sat, May 7, 2016 at 12:17 PM, Andrew Bennett <cacoyi at gmail.com> wrote:

> Hi Dave,
>
> Sorry, Dave, sending a second time as I forgot to Reply-All.
>
> I agree, this proposal doesn't allow multiple closures where only one of
> them should be run, and it should only be run once. I personally don't
> think lacking that functionality is worth blocking this proposal for,
> another proposal can be built on top of this if it is desired.
>
> These cases can also be handled by a more meaningful if/switch statement,
> using @noescape(once), for example:
>   let x: Int
>   functionThatCallsAClosure(someTest()) { x = $0 ? 1 : 2 }
>
> On Sat, May 7, 2016 at 6:24 AM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> on Tue May 03 2016, Chris Lattner <swift-evolution at swift.org> wrote:
>>
>> > Hello Swift community,
>> >
>> > The review of "SE-0073: Marking closures as executing exactly once"
>> > begins now and runs through May 9. The proposal is available here:
>> >
>> >
>> https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.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 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?
>>
>> I think it's of questionable importance and doesn't generalize well.
>> For example, you can't use this to construct something like
>>
>>   var x: Int
>>   functionThatActsLikeIf( someTest(), then: { x = 1 }, else: { x = 2} )
>>
>> If you need to initialize something in an outer scope with something
>> computed by a closure, it's much better to arrange something like this:
>>
>>   var x = functionThatActsLikeIf( someTest(), then: {  1 }, else: { 2 } )
>>
>> --
>> Dave
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160507/e8d1f681/attachment.html>