Type-constraint generic protocols by their non-primary associates types according to SE-0346?

Evolution Discussion
1

Reading the comments left in the first review of SE-0346. It seems to be that Index Is not a primary associated type for Collection.

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.

No more 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.

2

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.

4 Likes
3

There might be, but it'll require its own evolution proposal.

4

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