[SR-3762] Default implementation of index(after:) for Integer indices

[airspeedswift]

Previous ID	SR-3762
Radar	rdar://problem/26476285
Original Reporter	@airspeedswift
Type	Improvement

Additional Detail from JIRA

Votes	0
Component/s	Standard Library
Labels	Improvement, AffectsABI, StarterProposal
Assignee	None
Priority	Medium

md5: 0a15e4ebe05ad3320d3ce0d815461616

Issue Description:

There should be a default implementation for Collections whose Index type is Int. This make it more convenient to write integer indexed collections. In the previous collections model it was just understood that an Int index’s successor was the integer + 1 and there was no boilerplate a developer had to write.

extension Collection where Index: Integer {
public func index(after i: Index) -> Index {
return i + 1
}
}

Note, this would mean that collections that did not want this behavior (say, they used a non-unit stride) would need to remember to override this. However, since users can just do integer calculations themselves without using the collection, it would probably be wise for these types to create an opaque index type to wrap the integer in anyway.

This would need an evolution proposal. Part of the initial pitch should include whether this should be done to just Collection or be specific to RandomAccessCollection.

[natecook1000]

This more or less already exists for RandomAccessCollection—the constraints on the default implementations are Index : Strideable, Index.Stride == IndexDistance, Indices == CountableRange<Index>. The last one of those adds the constraint that Index.Stride is an integer, which seems like what we would want to specify rather than the index itself.

Are there collections that could use an integer for their index but couldn't be random access? Or could/should use a non-unit stride? I think if startIndex..<endIndex turns into a countable range, there should probably be a valid element at each index.