a) I agree with you, I'm surprised it ever compiled. I don't think we'll fix this one.
b) This one we've seen before; it's tracked internally at Apple by rdar://problem/30176166.
c) This one is still a problem. 1-tuples aren't supposed to be allowed at all in Swift, so the fact that you can write this at all is an error, but now it's a source compatibility issue and we can't change it until Swift 4.
d) This one is rdar://problem/30167924.

Let's use this bug to track (c), since that's the only one I don't think we've seen before.

Reduced:

func foo(completion: ((didAdjust: Bool)) -> Void) {
    completion((didAdjust: true))
}

@swift-ci create

Are 1-tuples really banned? If so, we should prohibit them in Swift 4 mode. Right now we have some half-assed logic in a few places that diagnoses when they come up, but it's not very thorough.

Comment by Diego (JIRA)

If I can say something, I'd prefer to have the ability to use 1-tuples. Maybe it's a workaround here for the lack of labeled arguments in closure, but maybe there are some other uses for them. I don't see them hurting from the user point of view.

Related to this, do you have plans to recover labeled arguments at call site for closures in Swift 4? If I remember correctly that was the plan moving forward in that polemic evolution thread.

These are discussions for swift-evolution, not the bug tracker. :-) The priorities here are

(1) make sure things that worked in Swift 3.0 work in Swift 3.1
(2) get the implementation model closer to the current language model.

All tuple types contain two or more types, except for Void which is a type alias for the empty tuple type, (). A single parenthesized type is the same as that type without parentheses.

(https://developer.apple.com/library/prerelease/content/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/doc/uid/TP40014097-CH31-ID448)

cc @DougGregor, @jckarter

I would say conceptually that unlabeled 1-tuples do exist, but that they are synonymous with the one element type. The prohibition against labeled 1-tuples was motivated by type system problems dealing with the slushy rules around labeled/unlabeled tuple conversions, and the interaction with edge cases due to unlabeled 1-tuples being non-canonical. We've significantly reduced the scope of the problem by tightening up the compound-function-name and multiple-function-arguments models since Swift 1, so maybe that's less problematic than it used to be when every function argument was a tuple. We could also tighten up the conversion rules around tuple labels to eliminate the circular relationship between labeled and unlabeled tuples—maybe say you can convert labels off, but not back on?

Talking to Slava, it sounds like it would be pretty risky and fragile to try to continue accepting this code in 3.1, since a lot of the type checker has "moved on" and jettisoned the special cases that were necessary to try to handle single-element tuples in various places. In #7279 I improved the code that checks for them so you at least get a clearer error message when you try to summon them.

Comment by Slipp Douglas Thompson (JIRA)

Heads-up: I just saw this bug mentioned in the Xcode 8.3 beta 5 Release Notes, in which it's recommended to replace func foo(x: ((y: Int)) ->; Int) with func foo(x: (Int) ->; Int)). However, the suggested replacement won't actually compile— it has 2 opening
“(”s and 3 closing “)”s.

I believe this is just a double-“)” typo; though it's probably worth fixing before the Xcode 8.3 final Release Notes, since the way its currently written could confuse a bunch of users and lead to a bunch of extra Swift bugs being filed over nothing.

Comment by Myke Olson (JIRA)

Thanks for the heads up, capnslipp (JIRA User). We're working on getting the release note updated.

Closing this issue now that there's a good diagnostic.