Most of the time I'd only want to use a labelled 1-tuple (I've often wished I could use one as a return value from a method). However, I think once variadic generics are available in the future, the use case gets stronger, and not including 1-tuples requires implicit splats by the compiler.
For example, I've got a series of methods in one codebase with the signature:
func reallocate<A>(capacity: Int) -> (UnsafeMutablePointer<A>)
func reallocate<A, B>(capacity: Int) -> (UnsafeMutablePointer<A>, UnsafeMutablePointer<B>)
func reallocate<A, B, C>(capacity: Int) -> (UnsafeMutablePointer<A>, UnsafeMutablePointer<B>, UnsafeMutablePointer<C>)
These are currently auto-generated from a template. Now, if variadic generics were available, this would become one method. Given that, it makes more sense to me that the following should match:
var a: UnsafeMutablePointer<Int>
var b: UnsafeMutablePointer<Float>
(a) = allocator.reallocate(capacity: 10)
(a, b) = allocator.reallocate(capacity: 10)
and that the return value of the one-tuple-returning method shouldn't get implicitly converted to its value; i.e. that the syntax shouldn't be:
a = allocator.reallocate(capacity: 10) // should be invalid, but currently is accepted.
since the return type is a tuple, not its contents. Of course, I don't know what removing that implicit splat would do to source compatibility and I'm guessing the breakage would be fairly significant. Still, it's an argument for a no-label 1-tuple.