[swift-evolution] Strings in Swift 4

[Brent Royal-Gordon]

> On Feb 1, 2017, at 2:30 PM, Nate Cook via swift-evolution <swift-evolution at swift.org> wrote:
> 
> With a lot of these new features, it helps me greatly to see them in action. I've built a poor man's version of these incomplete ranges in a Swift Sandbox here:
> 	http://swiftlang.ng.bluemix.net/#/repl/58925f5d42b65e6dce9a5bea
> 
> This implementation suffers greatly from a lack of generic subscripts, and the type names are terrible and not at all suggestions. Otherwise, as far as I can tell, the behavior of the one-sided ranges correctly matches what Ben is describing here — if you're unsure about how this will look and behave in practice, please take a look.

I actually have a pull request with a partially finished implementation: <https://github.com/apple/swift/pull/3737/files>

Unfortunately, that pull request is full of GYB garbage, rips out a lot of code, and doesn't merge cleanly into the current master, so I've extracted much of it and adapted it into a playground that people can try out. <https://www.dropbox.com/s/kiy8q4w1qgr4xhv/IncompleteRangePrototype.playground.zip?dl=0> 

The actual implementation is in the "Sources" folder. The most important difference from your prototype is that the types are designed quite differently. The operators create instances of types which, at their core, look like these:

	public struct IncompleteRange<Bound: Comparable> {
		public let lowerBound: Bound?
		public let upperBound: Bound?
	}
	public struct IncompleteClosedRange<Bound: Comparable> {
		public let lowerBound: Bound?
		public let upperBound: Bound?
	}

Thus, while the normal case is that only one bound will be filled in, you could create an `IncompleteRange` with both bounds or neither bound filled in.

This prototype is based on a slightly earlier design, so it has a few differences from the most popular designs we've discussed:

1.	An `IncompleteRange` with a missing upper bound is spelled `i..<`, an `IncompleteClosedRange` with a missing upper bound is `i...`. That ends up meaning that `ary[i...]` will almost certainly crash, and you need to use `ary[i..<]`.

2.	This also includes infix `..<` and `...` operators, which vary from the conventional ones because they accept optional bounds. That allows for dynamic construction.

3.	The types include `completed(by:)` methods which take ranges to fill their bounds from. In other words, these are truly modeled as *incomplete* ranges that you're expected to fill in, not *unbounded* ranges that are infinite; 

4.	This includes a number of workarounds and hacks we'd like to ultimately get rid of.

5.	This does *not* include `contains(_:)` or `~=` implementations.

Obviously these points can be debated and corrected; you could even pop into the "Sources" directory and fix them yourselves if you want to try them out.

Hope this helps,
-- 
Brent Royal-Gordon
Architechies