[swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

Brent Royal-Gordon 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.

-- 
Brent Royal-Gordon
Architechies



More information about the swift-evolution mailing list