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
···
On May 20, 2016, at 10:25, John McCall <rjmccall@apple.com> wrote:
On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 14, 2016, at 22:16, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
So anyway, how hard a problem is this to fix? And do you want me to submit the proposal as a PR or not?
-- E
···
On May 20, 2016, at 11:34 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
On May 20, 2016, at 10:25, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 14, 2016, at 22:16, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
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.
···
On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On May 20, 2016, at 11:34 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 20, 2016, at 10:25, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 14, 2016, at 22:16, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
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
···
On May 20, 2016, at 11:42 AM, John McCall <rjmccall@apple.com> wrote:
On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 20, 2016, at 11:34 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 20, 2016, at 10:25, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 14, 2016, at 22:16, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
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.
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.
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.
I do not feel strongly that you should have to do *anything* to ignore arguments. It should be magical.
Right, this was directed to other people.
Thus, it sounds like I should kick back and cross this off my "take action" list. Right?
Sounds good to me!
John.
···
On May 20, 2016, at 10:46 AM, Erica Sadun <erica@ericasadun.com> wrote:
On May 20, 2016, at 11:42 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On May 20, 2016, at 10:37 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 20, 2016, at 11:34 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 20, 2016, at 10:25, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 14, 2016, at 22:16, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
