Re: [swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

On 05.07.2016 8:39, Greg Lutz via swift-evolution wrote: Vladimir.S via swift-evolution writes: Proposal: === 1. Separate function types with parameter list and a tuple parameter. They should be two separate types. 2. Require this syntax to assign tuple

Re: [swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

Vladimir.S via swift-evolution writes: > > Proposal: > === > > 1. Separate function types with parameter list and a tuple parameter. They > should be two separate types. > > 2. Require this syntax to assign tuple parameter's sub-values to variables > in

Re: [swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

+1 to this; I seem to keep running into cases of this, and it crops up especially when Swift is having difficulty inferring a type, which can be tricky to debug as it is, so I think it's better to just be consistent and explicit, with double brackets for all tuple type closures as proposed. >

Re: [swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

+1. I had this same problem when using map with enumerated-both $1 and $0.offset worked. I can see how this can be confusing to beginners. On Sat, Jun 25, 2016 at 8:36 AM Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > I believe this should be done for Swift 3.0 release as

[swift-evolution] [Proposal] Disallow implicit conversion between function/closure with a list of parameters and with tuple parameter. Remove function type inconsistency.

I believe this should be done for Swift 3.0 release as this is a *source breaking change* and IMO it is very important to remove the inconsistency mentioned below. We removed tuple splatting on caller side and IMO we must complete this job to delete the implicit connection between tuple and