I really think we need more convenient APIs for collections, but I'm not convinced that this proposal is the best solution.
There are alternatives which allow context-sensitive anchors, thus offering much more flexibility. Those alternatives might have serious downsides as well, and if somebody can present me a proper rationale, I'd certainly support SE-0265 as an improvement of the status quo.
However, that didn't happen yet, so currently I'm firmly against this proposal.
What is that alternative?
The current proposal has two possible anchors (.first and .last). For arbitrary collections, there's not much we can do here, but in many cases (String as the most prominent example), there way more than only those two positions:
You might want the index of the first Double that's bigger than a given threshold, or the first character in a string that can be converted to a number...
It would still be possible to use
(line[.first + 5]!, line[.last - 11]!)
but you could also create expressions like
let value = line[.find("=") ..< before(";")]
Here, instead of an enum, .first and .last are static var properties of RelativeIndex, and find would be a static func of that type - and with extensions, you could have as many of those as you like.
There's a prototype of this alternative design, and I think its extended capabilities shouldn't be discarded without even talking about them.
The odd thing for me is that [Prototype] Protocol-powered generic trimming, searching, splitting, - #7 by SDGGiesbrecht basically has all those features which could also be used for basic indexing into collections as well 