> On May 20, 2016, at 11:42 AM, John McCall <[email protected]> wrote: > >> On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >>> On May 20, 2016, at 11:34 AM, Jordan Rose via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>>> On May 20, 2016, at 10:25, John McCall <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> On May 14, 2016, at 22:16, Chris Lattner via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>> This encourages the use of empty closures over optional closures, >>>>>>>> which I think is open for debate. In general I try to avoid optionals >>>>>>>> when they can be precisely replaced with a non-optional value. >>>>>>>> Furthermore, most Cocoa completion handlers are not optional. >>>>>>>> >>>>>>>> The alternative is to not do this, but encourage that any closure that >>>>>>>> could reasonably be empty should in fact be optional. I would then >>>>>>>> want Cocoa functions with void-returning closures to be imported as >>>>>>>> optionals to avoid "{ _ in }". >>>>>>> >>>>>>> +1. In general, I think we should allow implicit arguments, without >>>>>>> requiring the closure to use all the implicit $n variables like we do >>>>>>> today. These should all be valid: >>>>>>> >>>>>>> let _: () -> () = {} >>>>>>> let _: (Int) -> () = {} >>>>>>> let _: (Int, Int) -> Int = { 5 } >>>>>>> let _: (Int, Int) -> Int = { $0 } >>>>>>> let _: (Int, Int) -> Int = { $1 } >>>>>> >>>>>> I agree, but I consider this to be an obvious bug in the compiler. I >>>>>> don’t think it requires a proposal. >>>>> >>>>> Sorry to find this thread late. I don’t think this is just a bug; it’s >>>>> also a way to check that a parameter isn’t getting forgotten. For a >>>>> single-expression closure that’s probably overkill, but maybe we’d keep >>>>> the restriction for multi-statement closures? >>>> >>>> The bug we're talking about is that closures have to have a reference to >>>> $n when there are n+1 parameters. >>> >>> Oh, I completely forgot that it’s only $n you have to reference, not $n-1 >>> or anything else. So I guess it’s not quite serving the purpose I thought >>> it was. >>> >>> Jordan >> >> Who knew? http://i.imgur.com/8ytNkn0.jpg <http://i.imgur.com/8ytNkn0.jpg> ! >> >> So anyway, how hard a problem is this to fix? And do you want me to submit >> the proposal as a PR or not? > > Not requiring you to refer to the last argument is a bug fix, and not > requiring "_ in" will fall out from that fix. I think that means there's > nothing left to propose. If anyone feels strongly that you should have to do > *something* to ignore arguments, at least if you're ignoring all of them, > that should be its own proposal. > > John.
History to date: 1. draft proposal: https://gist.github.com/erica/3731e24fc252c8e66850e0e02f491281 <https://gist.github.com/erica/3731e24fc252c8e66850e0e02f491281> 2. bug report: https://bugs.swift.org/browse/SR-1528 <https://bugs.swift.org/browse/SR-1528> (although it seems the bug is wrongly named, and should be "requires reference to ultimate anonymous argument, not all arguments) I do not feel strongly that you should have to do *anything* to ignore arguments. It should be magical. Thus, it sounds like I should kick back and cross this off my "take action" list. Right? -- E
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
