[Pitch] One-Element Tuples

[xwu (Xiaodi Wu)]

@Slava_Pestov

However, we are not proposing introducing any new implicit conversions between one-element tuples and their corresponding element type:

• An expression of type (label: T) does not implicitly convert to a value of type T or vice versa.
• An expression of type (_: T) does not implicitly convert to a value of type T or vice versa.

@Slava_Pestov

We could allow the implicit conversions that are explicitly called out as not supported in the Detailed design section above. While this is probably not too difficult to achieve in principle, we generally favor not introducing new implicit conversions by default.

True, but an implicit conversion would seem to fall naturally out of ordinary tuple destructuring with label introduction/elimination, would it not? Seen in that way, it’d not be a “new” implicit conversion.

@Slava_Pestov

We chose (_: elt) for unlabeled one-element tuples since it is an existing production in the Swift grammar, in both type and expression context.

Would this proposal also, so as not to have to introduce any rules solely for the 1-tuple, and so that users who happen to start with a 1-tuple can append additional elements in source code without editing the first element (or use a source code generator that doesn’t need to apply a special rule for n = 1), permit explicitly label-less tuples of higher arity with the same syntax—e.g., (a: 42, _: "foo", c: false)?

@Slava_Pestov

In Swift 5.6, the type (_: T) resolves to T and the expression (_: expr) evaluates to expr. This proposal breaks source compatibility with code that uses these forms. We strongly suspect there are little to no projects making use of this syntax, but we wish to call it out as a potential incompatibility.

Having an implicit conversion between the 1-tuple and its only element would mitigate this (rare) source incompatibility to be essentially a non-issue, which I think is another nice point in favor of including it