Sent from my iPad
> On May 6, 2016, at 10:10 PM, Andrew Bennett via swift-evolution > <[email protected]> wrote: > > Replies inline: > >> On Sat, May 7, 2016 at 12:37 PM, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >> on Fri May 06 2016, Andrew Bennett <[email protected]> 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 >> > <[email protected]> wrote: >> > >> > on Tue May 03 2016, Chris Lattner >> > <[email protected]> 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 >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> >> -- >> Dave >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
