Length constraints seem too rigid and domain-specific, so I think they should be left out of the first version of the typles feature. The length(T...) function seemingly returns an integer, which user may expect to not only support equality operations but also comparisons, as Nate shows:
I think two other features should be established before we get same-length constraints, tuple conformances, and compile-time expressions in where clauses.
Tuple conformances is the most straightforward one, as there is arguably a parallel with other types. Similar to how many types are expressible by integers, but the built-in integer types are usually the backing storage, tuples could provide a built-in way of manipulating parameter packs. Under the current version of the pitch, tuples can only provide storage for parameter packs in types. But this could extend to other capabilities for generic element manipulation, such as gauging the length of typles, comparing elements for equality, etc. Some features in the feature directions, such as magic map and equality comparisons, could be built into tuples, instead of abstract parameter-pack types.
Compile-time expressions in where clauses are more intricate. Here's how the syntax could look:
struct TenElementBuffer<Element> {
// Storage...
subscript(
position: Int
) -> Element where position >= 0, position < 10 { ... }
}
This feature would require that the expression in the where clause be inlinable and a compile-time constant. This feature would allow for really powerful static checks, that should be part of the function contract. It's important to note that this would not just be a warning, but an actual requirement, which is why it'd be useful for typles.
Tying these features together, I propose that we use the following syntax:
func sameLength<T..., U...>(_ a: T..., b: U...) where (a...).count == (b...).count {}
Contrary to the pitch, T... and U... are used in parameters, which is consistent with the current rule that all generic parameters in functions must be used in the signature. Also, instead of using a built-in length function (?), the compile-time count property of the tuples unpacking a and b are used. Perhaps it'd be better if there was an operation on the tuple types themselves to get the length, which should arguably be implemented by conforming the tuple metatype to Collection, but that is not a requirement for version one.
To reiterate, having compile-time expressions as checks in the function signature is more expressive and would open up more capabilities when constraining the arity or other compile-time aspects of typles.