> On Jul 25, 2016, at 1:46 PM, Pyry Jahkola via swift-evolution > <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
