These are good points!
I missed that some/any will be usable in type position! I love how elegantly that solves the problem.
I support the sentiment for requiring all type parameters, that others have expressed in the thread. This, or perhaps supporting defaults by some other means.
For the types provided in the standard library, there's no need for
Collection<Index, Element>, I'll give you that. However, I think there could well valid reason to include Index on a Collection-like protocol. I could foresee a framework providing families of concrete collection types, such as contiguous or linked lists optimised for different use-cases, and users writing code to be generic over them, sometimes requiring
Index == Int perhaps, but other times not. But to counter my own point, perhaps a new protocol would be needed for this use-case, to more finely define Array-like behaviour as a requirement.
I'm now cautiously supportive of your stance that Index isn't needed, and that things wont spiral out of control with everything becoming a primary type; the latter especially if we require all primary types be written out, no defaults.
One last thought. As a user, if I wished to use
Collection<Index, Element>, but only
Collection<Element> were provided, could I use a typealias for this?
typealias Collection<Index, Element> = Collection where Self.Element == Element, Self.Index == Index
func foo() -> some Collection<Int, String>
I forget whether this kind of typealias is meant to be supported, now or in the future, but if so, doesn't it rather fulfil the need this feature seeks to meet without any new syntax?
(I ask, expecting to be met with sound reasoning once more. )