At the implementation level, I actually already added a "fake" Builtin.TheTupleType type with a generic signature <Elements...> that we can hang tuple conformances and extensions off of. So internally the compiler uses the same mechanism here as member lookup and conformance checking for nominal types. This won't be exposed to users though, like the rest of the Builtin module it's an implementation detail.
It's more that adding a new Tuple type to the standard library probably wouldn't simplify the language a whole lot, once you consider that the compiler still needs to special-case various behaviors involving it.
I just remembered another one -- the implicit conversion from (T, U, ...) -> () to ((T, U, ...)) -> () for closure values passed as function arguments.
The tuple labels thing sounds like the most source breaking possibility, and I would love to know if you think that this thing I posted the other day and tagged you and @hborla in is a relevant idea/could change anything
Your idea of adding named generic arguments is interesting, and I think we can explore this possibility at some point. However what we'd need to make struct Tuple<T...> a drop-in replacement for built-in tuples is a bit different; we want the concrete substitution for the Elements generic parameter to carry labels, so, eg if you instantiate the type with Tuple<a: Int, b: String>, then any mention of T... in the body preserves the labels a:b:. For example,
extension Tuple {
func toArray() -> Tuple<Array<T>...> {}
}
let x = Tuple<a: Int, b: String>.toArray()
// x has type Tuple<a: Array<Int>, b: Array<String>>
It's also not clear how function calls would actually work, eg how do you call f() with T := {a: Int, b: String}? Since the parameter is unlabeled, perhaps f(a: Int, b: String) makes sense:
func f<T...>(_: T...) {}
But what if it has a label?
func f<T..., U...>(t: T..., u: U...) {}
I actually think we could one day solve these problems (or just say that labeled packs can only appear in a subset of the positions where packs can appear today) and support this in the future in a forward-compatible way, but maybe it's best to subset it out for now.
(I'm actually not a huge fan of labeled tuples at all! If I was designing a new Swift-like language from scratch, I would probably omit them entirely).