Improve extensions for RandomAccessCollection about composed HOT 5 CLOSED

In this case the consumer's implementation would still be used right?

I think it errors but I've not tried.

I also don't know if we have such a huge number of other consumers atm hahah

Yeah probably not many, but I don't think it looks great to break semantic versioning.

There are a few little teething issues we've run in to I don't think a 2.0 would be out of the picture, even if we just start with 2.0.0-beta, 2.0.0-beta.2 etc. for a few releases.

from composed.

So I was going to do this but felt conflicted about the impact it would have on Single element sections. Thoughts @JosephDuffy ?

from composed.

CollectionOfOne conforms to RandomAccessCollection so while I agree it's not the most logical thing there's precedence.

It might impact API though, if a consumer has already added RandomAccessCollection conformance to Section?

from composed.

CollectionOfOne is a good shout. I was actually thinking about that as well.

True but I don't think we can consider all the extensions a consumer might add. Its similar (although I realise not the same) as when we got automatic Hashable support in Swift for example, requiring us to delete a lot of code, thankfully!

In this case the consumer's implementation would still be used right?

I also don't know if we have such a huge number of other consumers atm hahah

from composed.

Guess this was never feasible, closing

from composed.