This review ended on October 21st, but because of the LLVM conference, the Core Team didn't have an opportunity to discuss it until last week.
Swift's indexing model is based on solid concepts that have held up well over the years, but the verbosity of expressing positions at integer offsets from known indices has been a persistent pain point. The Core Team feels that this is a significant problem and is very happy to see a proposal aimed squarely at it.
OffsetBound allows the expression of abstract indices that aren't actually valid in a collection. During the review, it was pointed out that, rather than responding to this by clamping or reporting an error, we could use it to improve expressivity: for example, if the user inserts something at .last + 5 , we could pad out to that index with some (user-provided) padding element. The Core Team discussed this idea and ultimately decided to reject it. We feel that it provides a simpler and more consistent programming experience overall if abstract indices can always be thought of simply as sugar for computing a specific valid index.
It was also pointed out that anchoring abstract indices at the beginning and end of a collection is fairly limiting; there are plenty of other interesting ways of deriving indices, like finding the first index that matches a predicate. The Core Team feels that it should not be a goal of this feature to totally replace the need to work with concrete index values. In particular, this shouldn't become an arbitrarily-complex expression-template language.
That said, it's important that abstract indices compose nicely with concrete indices. Programmers should feel like they can reliably use abstract indices anywhere they could use concrete indices. That doesn't appear to be true of the current proposal: in particular, programmers can slice between two abstract indices or between two concrete indices, but not between a mix of either. The Core Team feels it's important to avoid this kind of inconsistent-feeling experience.
Along the same vein, abstract indices can only be anchored relative to the start and end of a collection. It is frequently useful to be able to anchor relative to a concrete index, e.g. to slice from an index returned by firstIndex(where:) to the fifth element past that. This pattern is not addressed by the current proposal, and it's not clear whether the proposal can be extended this way in the future.
If necessary, the Core Team is willing to consider new language support for slicing subscripts, either through new syntax or through new interpretations of existing syntax.
The proposal author also requested an opportunity to revise the proposal's treatment of certain methods on RangeReplaceableCollection .
Accordingly, SE-0265 is returned for revision.
As ever, thank you for contributing to Swift; your reviews are a vital part of making the language better.
John McCall
Review Manager