# Offset Indexing and Slicing

**URL:** <https://forums.swift.org/t/offset-indexing-and-slicing/28333>\
**Category:** Pitches\
**Created:** [August 28, 2019, 6:45pm UTC](https://forums.swift.org/t/offset-indexing-and-slicing/28333 "2019-08-28T18:45:24Z")\
**Posts on this page:** 4\
**Page:** 6

<div class="post-metadata">

**Author:** ![Lantua](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lantua/32/8868_2.png) [@Lantua](https://forums.swift.org/u/Lantua)\
**Post date:** [February 21, 2020, 5:37pm UTC](https://forums.swift.org/t/offset-indexing-and-slicing/28333/103 "2020-02-21T17:37:20Z")

</div>

The pitch went into review in and was returned for revision in [SE-0265](https://github.com/apple/swift-evolution/blob/master/proposals/0265-offset-indexing-and-slicing.md).

Maybe you can check out the discussion there, as well as the rationale for decision. If you think there's something new that can be added, maybe you can also start a new thread.

PS

I also have similar problem, and ended up rolling my own `subscript[offset: Range<Int>]`.

---

<div class="post-metadata">

**Author:** ![Michael\_Ilseman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michael_ilseman/32/44640_2.png) [@Michael\_Ilseman](https://forums.swift.org/u/Michael_Ilseman)\
**Post date:** [February 21, 2020, 6:15pm UTC](https://forums.swift.org/t/offset-indexing-and-slicing/28333/104 "2020-02-21T18:15:06Z")

</div>

Specifically:

> [@\[Returned for revision\] SE-0265: Offset-Based Access to Indices, Elements, and Slices](https://forums.swift.org/t/returned-for-revision-se-0265-offset-based-access-to-indices-elements-and-slices/30503/1):
>
> 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.

In effect, it would be really nice to be able to mix an OffsetBound with an Index in some kind of range expression. But doing so may require re-thinking everything from Swift's subscript syntax to new hierarchies of range expressions. This sorta blew open the investigation area to a degree where I was unable to make progress at that time, and it could be a while before I can re-visit this.

---

<div class="post-metadata">

**Author:** ![QuinceyMorris](https://avatars.discourse-cdn.com/v4/letter/q/d26b3c/32.png) [@QuinceyMorris](https://forums.swift.org/u/QuinceyMorris)\
**Post date:** [February 21, 2020, 7:48pm UTC](https://forums.swift.org/t/offset-indexing-and-slicing/28333/105 "2020-02-21T19:48:58Z")

</div>

I think it's inarguable that solving index-relative offsetting is a Really Hard™ problem. It's really hard to come to a decision about what "relative" should mean here, and it might be really hard to solve the `Comparable` conformance problem we're stuck with in `RangeExpression`.

In that case, might it not be sensible to ask whether it's at all _ **likely** _ that any future relative offset solution would require a source-breaking change to the current limited proposal, and would the answer to that not be a pretty big "no, not likely"?

In _ **that** _ case, might it not be sensible to ask for a re-review of the current proposal, with the above in mind? The longer this problem goes unsolved, the greater the accumulated pain to developers, and the better an incomplete solution starts to sound.

---

<div class="post-metadata">

**Author:** ![possen](https://avatars.discourse-cdn.com/v4/letter/p/ed8c4c/32.png) [@possen](https://forums.swift.org/u/possen)\
**Post date:** [May 25, 2020, 8:28am UTC](https://forums.swift.org/t/offset-indexing-and-slicing/28333/106 "2020-05-25T08:28:29Z")

</div>

This is a good proposal and we definitely need something like this. What I like about Python's **str[10:-3]** approach is that is easy to read but as was pointed out, is not possible to be performant on strings. Adding the **[.start+5....end-3]** at the beginning of the word is more difficult to read, then adding the range operator leads needing grouping parenthesis to the make the plus clear that we are offsetting.

I propose this could be done with labeled parameters in subscripts we have today, and would still emphasize the offset nature of the indexes:

```
str[startIndex: +10, endIndex: -5] // 10 from start, five from end
str[startIndex: +10, length: 3] // 10 from start goes for 3
str[startIndex: +10] // 10 from start goes to end
str[startIndex: -10] // start ten from end of string. 
str[endIndex: -5] // beginning to 5 from end.    
str[endIndex: +5] // start to end index five from beginning
str[length: 3] // first three chars. 
str[] // go from start to end like python [:] and create a substring. 

```

The plus would be optional, and could be a convention, but I think it might make it clearer the intent. I think It is hard to express cleanly with the range operator. This gives a lot of the power of the Python slice while making offsets clear.The plus and minus work the same as python. Plus means from beginning offset, minus means from end index. This will be familiar to python and ruby programmers.

[Previous page](https://forums.swift.org/t/offset-indexing-and-slicing/28333.md?page=5)