[swift-evolution] Strings in Swift 4

Brent Royal-Gordon brent at architechies.com
Wed Feb 1 06:58:09 CST 2017


> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Therefore I'd conclude that `arr[upTo: i]` is the most consistent spelling. It also yields the sensible result that `arr[from: i][upTo: j] == arr[upTo: j][from: i] == arr[i..<j]`.

There's a lot I dislike about `subscript(upTo/through/from:)`:

1. We have not previously been very satisfied with how understandable these labels areā€”for instance, we fiddled around with them a lot when we were looking at `stride(from:to/through:by:)` in Swift 3, and eventually settled on the originals because we couldn't find anything better. I don't think entrenching them further makes very much sense.

2. The fact that you *can* write `arr[from: i][upTo: j]`, and that this is equivalent to both `arr[upTo: j][from: i]` and `arr[i..<j]`, seems a bit weird. We aren't typically in the habit of providing redundant APIs like this.

3. Neither Stdlib nor the Apple frameworks currently contain *any* labeled subscripts, so this design would be unprecedented in the core language.

4. After a new programmer learns about subscripting with two-sided ranges, removing one of the bounds is a straightforward extension of what they already know. The argument label solution is more ad-hoc.

5. The argument label solution solves the immediate problem, but doesn't give us anything else.

To understand what I mean by #5, consider the implementation. The plan is to introduce a `RangeExpression` protocol:

	protocol RangeExpression {
		associatedtype Bound: Comparable
		func relative<C: Collection(to collection: C) where C.Index == Bound -> Range<Bound>
	}

And then reduce the many manually-generated variants of `subscript(_: Range<Index>)` in `Collection` to just two:

	protocol Collection {
		...
		subscript(bounds: Range<Index>) -> SubSequence { get }
		...
	}
	
	extension Collection {
		...
		subscript<Bounds: RangeExpression>(bounds: Bounds) where Bounds.Bound == Index -> SubSequence {
			return self[bounds.relative(to: self)]
		}
		...
	}

This design would automatically, source-compatibly, handle several different existing types you can slice with:

* ClosedRange
* CountableRange
* CountableClosedRange

Plus the new types associated with incomplete ranges:

* IncompleteRange
* IncompleteClosedRange

Plus anything else we, or users, might want to add. For instance, I have a prototype built on `RangeExpression` which lets you write things like:

	myString[.startIndex + 1 ..< .endIndex - 1]

This strikes me as a pretty cool thing that some people might want. 

Similarly, IncompleteRange and IncompleteClosedRange can most likely be put to other uses. They could easily fill a gap in `switch` statements, which don't have a good way to express open-ended comparisons except with a `where` clause. As some have mentioned, when applied to a `Strideable` type they *could* be treated as infinite sequences, although it's not clear if we really want to do that. And, you know, sometimes you really *do* have a case where one or both bounds of a range may be missing in some cases; incomplete ranges are a built-in, batteries-included way to model that.

To put it simply, slicing with incomplete ranges gives us several valuable tools we can apply to other problems. Labeled subscripts, on the other hand, are just another weird little thing that you have to memorize, and probably won't.

-- 
Brent Royal-Gordon
Architechies



More information about the swift-evolution mailing list