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
