[swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names
brent at architechies.com
Tue Jul 26 04:05:53 CDT 2016
> On Jul 25, 2016, at 1:46 PM, Pyry Jahkola via swift-evolution <swift-evolution at swift.org> wrote:
> I find the introduction of unary operators confusing. I don't think it's good design that you need to remove a space when moving from the old syntax to the new one:
> array[array.startIndex ..< someIndex] // before
> array[..<someIndex] // after
> and likewise, that you need to add parentheses here:
> array[array.startIndex ..< someIndex - 1] // before
> array[..<(someIndex - 1)] // after
> OTOH, I would be okay if the proposal didn't implement unary operators but only the Optional<Index> overloads of `...` and `..<`:
> array[nil ..< someIndex] // first example
> array[nil ..< someIndex - 1] // second example
The proposal includes both infix and prefix/postfix forms because the tradeoff between the two is rather complex.
The advantages of infix are:
* Closer to the non-incomplete Range syntax
* Permits spacing for readability
* Allows for `Index?` bounds, so you can choose at runtime whether or not to provide a particular bound
* Doesn't take leading or trailing `...`, which we may want for other purposes
* Doesn't require new operators to be declared
The advantages of prefix and postfix are:
* Don't add overloads (and thus type checker complexity) on existing ranges
* Don't use `nil` for "choose the end", which might be a little opaque
* Won't become potentially ambiguous if Optional becomes Comparable later
I think both syntaxes have a role to play, with the prefix and postfix syntaxes being useful for simple situations while infix can help with more complex ones. But I also think that it's a complex enough question that it's better to present both to the reviewers and core team so that more people can weigh in. I anticipated that one set might not survive review, and the design would be fine with only prefix/postfix, only infix, or both.
> That said, maybe it's best to defer that part of the proposal until a later time and stick to prefix(upTo:), prefix(through:), and suffix(from:) for now.
This is also an option. I hoped to make it in before Swift 3 so we could avoid a deprecation cycle, but the two parts *are* essentially severable.
More information about the swift-evolution