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

[Matthew Johnson]

Sent from my iPad

> On May 6, 2016, at 10:10 PM, Andrew Bennett via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Replies inline:
> 
>> On Sat, May 7, 2016 at 12:37 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> on Fri May 06 2016, Andrew Bennett <swift-evolution at swift.org> 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 }
>> 
>> Why is this better than
>> 
>>     let x = functionThatCallsAClosure(someTest()) { $0 ? 1 : 2 }
>> 
>> ?
>> 
> 
> I'm not saying it's better, neither is the proposal. I do think both are better than this though:
> 
>     functionThatActsLikeIf( someTest(), then: { x = 1 }, else: { x = 2} )
> 
> My opinion is that cases where the proposal are limited by multiple closures seem to be cases where you would be better off with a single closure and more explicit control-flow. I'd be interested if there are other cases, but it currently seems like a straw-man argument to me.
> 
> --
> 
> It may be useful if Swift allowed things like this:
> 
> let x = switch { ... }
> let x = if { ... } else { ... }
> etc.
>  
> I think that's a much larger change/discussion, with no clear victor.
> 
> However until Swift has that support it's necessary to consider separated initialization and declaration. Likewise until all Swift is pure functional.
> 
> Even if this proposal didn't let you assign to let statements outside the closure it still has value:
> It lets the type system reduce programmer error
> It allows protocol declarations to have a more explicit requirement
> The user can guarantee that their code, and its side-effects, will be executed

+1.

> 
>> IMO separating initialization from declaration is *very* rarely needed
>> and very much better avoided altogether, because it leads to code that's
>> less clear.  Just because we *can* do this doesn't mean we should.
>> 
>> > 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
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> --
>> Dave
>> 
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160506/7d8b4fcd/attachment.html>