If operator <+> is used in one domain area, and operator <-> is used in another domain area, then we should not make everyone keep in mind both domain areas simultaneously.
Another explanation: operator ... does not belong to "core", "control" operators, it belongs to Ranges part of standard library. Likewise, + operates on numbers. Therefore they should not have precedence relationship. Yet another explanation: I believe that optionals and booleans are a lot more fundamental in Swift than ranges. Ranges don't have any support in language itself, they belong to standard library. 2016-08-02 22:19 GMT+03:00 Xiaodi Wu <[email protected]>: > What's the benefit? Is there anyone confused by a...b+c? > > On Tue, Aug 2, 2016 at 14:13 Anton Zhilin <[email protected]> wrote: > >> 2016-08-02 21:56 GMT+03:00 Xiaodi Wu <[email protected]>: >> >>> I can sort of see what this is getting at, but I simply have no way of >>> evaluating whether it's sensible or not without actual examples in code. >>> This is, again, a more expansive change than discussed. I'd be interested >>> in seeing your write-up on separating arithmetic and bitwise/bitshift >>> operators :) >>> >> On Tue, Aug 2, 2016 at 1:36 PM, Anton Zhilin <[email protected]> >>> wrote: >>> >> Here's another possible plan: >>>> https://gist.github.com/Anton3/e00026409a6f948ca3ba41acf24e9672 >>>> >>>> There is a base line of "core", control-like operators, which everyone >>>> must know. "Applied" operators are branched off them. For example, Ternary, >>>> Comparison or Casting can be selected as base for a new mini-tree of >>>> related operators. >>>> >>>> Following this scheme, there are at least 3 "applied" domains with >>>> operators: arithmetic, bitwise and range formation. You can see result in >>>> the gist. >>>> >>> >> Well, I don't suggest changing precedence relationships there (just >> removing some), so that should be on-topic, I guess? >> >> The main change I suggest over separating bitwise operators is separating >> RangeFormation, because it's a separate, "applied" operator domain. It is >> not control-structure-like, so it does not deserve to be in the main tree. >> >> Simplifying even more, I want to prohibit this: a...b+c >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
