Spotted in the wild: http://stackoverflow.com/questions/39785389/why-does-for-index-a-b-in-dict-enumerated-produce-an-error

Another case of inconsistent tuple conversions. cc @slavapestov, @rudkx

It looks like Swift 4 doesn't allow even the simple case of matching count/element on an enumerated array—is that the intended behavior?

let a = [1, 2, 3, 4, 5]
let b = a.enumerated().map { (count, element) in "\(count): \(element)" }
// The error message is also unhelpful:
// error: cannot convert value of type 'String' to closure result type '_'

Yes, that one's correct. Closure arguments are not pattern matches. @xedin is working on improving this particular issue.

@natecook1000, it seems like what you describe is even stricter than what's reported in SR-4738?

@natecook1000 Your example is related to SR-4738 and it's going to produce following diagnostic:

<REPL Input>:1:30: error: closure tuple parameter '(offset: Int, element: Int)' does not support destructuring
let b = a.enumerated().map { (count, element) in "\(count): \(element)" }
                             ^~~~~~~~~~~~~~~~
                             (arg) -> <#Result#> let (count, element) = arg; return

But `for` loop diagnostics might require some more work though.

for-loops really are pattern matches and do support destructuring. Our handling of tuple labels is just inconsistent enough that some of these cases work and some don't.

@belkadan, wait, what?! Are you saying that the original example here is supposed to work?
Why does for-in loop get treated differently than closure arguments? That seems super inconsistent to me… What exactly is the difference between the variables you declare between for and in — that exist only inside the for-in block — and the closure arguments introduced before in keyword? As user I always thought they were the same!

One of these is assignment, like let, and one of them is defining parameters, like func. They're not actually related features at all, though I can see how a Haskell/ML person might want them to be.

To be fair, I'm not against adding destructuring-like capabilities to closures, but that would be a language change, and would have to go through the Swift Evolution Process.

@belkadan, what would adding support for destructuring tuples in closure arguments entail in the compiler? Is that completely new feature, or it could reuse what's in for-each?

It looks like Reitzig (JIRA User) was suggesting the same thing in comments to SR-2008… maybe we should jointly draft an SE proposal?

It's 80% a new feature. The compiler would have to figure out what the proper type of the closure is anyway (the hard part) and then assign from that type into local variables for the destructured parameters (the easy part).

Please do take it to swift-evolution if you're interested!

Any thoughts on requiring a let keyword to trigger the destructuting in order to remain source compatible as Reitzig (JIRA User) suggested in SR-2008? Wouldn't that make the implement significantly easier/able to reuse code from for-in? //cc CodaFi (JIRA User), @airspeedswift