I agree with @Jens; I think it'd be better to make tuple syntax a shorthand for initializing a contextual type (like .init(...) but without the .init) than to introduce a protocol for making certain types able to use tuple syntax. I can see many benefits to this:
- It doesn't need any new fundamental type system features to support the full functionality of tuple syntax, including variable numbers of arguments, preservation of the individual element types, labels, etc., since these can all be expressed as initializer overloads.
- It reduces the friction in migrating a tuple to a named type, if you outgrow the abilities of tuples.
- It would make expressing large, well-typed literals generally more streamlined, since you wouldn't need
.init(...)orT(...)prefixes that can be deduced from context. - Protocols need runtime support, and any new ones we add will be availability-gated by OS versions with new enough standard libraries to provide them. I think that indicates that protocol requirements are not a great idea for features that are intended primarily as compile-time syntactic conveniences.
A prototype implementation approach to experiment with this design direction would be to set up a constraint system when we see a tuple expression to make a disjunction between forming the tuple or looking for an init member in the contextual type, scoring the tuple case higher as the default.