Reading the comments left in the first review of SE-0346. It seems to be that
Index Is not a primary associated type for
Will there be a way to type-constraint generic protocols by their non-primary associated types?
My go to way currently to handle lazy collection with large types is
AnyRandomAccessCollection<T> but I noticed the benefit of exposing the index when it took away the ability to access its values using Int indexes.
values[(values.endIndex - 4)…] but
values[values.index(values.endIndex, offsetBy: -4)…]
Since the collection is exposed as public in my library, the ease of use at the users’ end I believe decreases.
These are not guaranteed to be equivalent. Collection types with
Int indices are not required to use consecutive integers for consecutive indices. In other words, the second index is not guaranteed to be the first index + 1.
There’s very little—if there is anything at all—you can do correctly manipulating indices of a collection in a generic algorithm constraining only the type of the index.
There might be, but it'll require its own evolution proposal.
Is there a discussion about how will the primary associated types be adopted into the standard library?
The SE-0346 mentions that it is out of the scope of the proposal.
UPDATE: It’s here: [Pitch] Primary Associated Types in the Standard Library