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
