@swift-ci create

Definitely a quirk of the closure inference rules. Let's take program B:

let b: [(id: Int, daata: String)] = foo(a) {
    return $0 // <-- this line at compile- instead of run time.
}

The single-expression closure causes the body to be treated as one big expression. That expression's type is bound to the function type (T) -> R. While the labels do not match, there's an applicable conversion: the argument labels don't matter for closures. So we insert a function conversion node and everything goes off without a hitch.

Now, for the multi-statement closure.

let b: [(id: Int, daata: String)] = foo(a) {
    // _ = () // <-- Uncomment this line to detect error on
    return $0 // <-- this line at compile- instead of run time.
}

We cannot treat the body as before, so we must instead make do with what we do have: T is contextually bound to `(id: Int, data: String)?` via the argument a, and the return type contextually bound via the user-provided type (id: Int, daata: String)?. As there is no valid conversion rule between tuples with different sets of labels, the return type constraint fails.

The takeaways: Despite being unintuitive, this behaves correctly. Now, does it behave intuitively? Absolutely not. The inference rules for multi-statement closures really ought to be revisited to make these cases consistent one way or the other.