Make "tuple syntax" a shorthand for initializing a contextual type

[xwu (Xiaodi Wu)]

@Joe_Groff

A good question to ask here is, why and how would a type's "how can I be instantiated from a tuple" be different from how it could be instantiated generally? I can think of at least one answer, which is the single-argument initializer case. Foo(x) makes sense to build a Foo from x , but (x) by itself would definitely be surprising if it could hide a type conversion.

This is the most compelling roadblock to the proposed idea, in my view. It would set up a clash among the following three principles that have long been settled:

• Swift's naming conventions explicitly tell users that T(x) is the preferred way to spell an API that converts a value x of type U to type T. The standard library uses this spelling consistently throughout, and these are now ABI-stable operations.
• Implicit conversions were deliberately avoided in the language.
• Single-element tuples are explicitly intended to be indistinguishable from their single element.

It would break these conventions to make (x) a type conversion operation from U to T.

---

My second concern is that it could be confusing--particularly for learners but also for readers of code more generally--that something that looks identical to tuples will actually have different rules.

As has been explained by @Jens in later posts, it's not his intention to make argument labels non-mandatory (wisely, in my view), even as tuples have automatic conversions between labeled and unlabeled counterparts. Moreover, argument shuffles wouldn't be allowed, while tuple shuffles are still a thing. Therefore, x = (foo, bar) would be subject to subtly different syntax rules depending on the type of x.