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: > 2016-08-02 21:09 GMT+03:00 Nevin Brackett-Rozinsky < > [email protected]>: > >> @Xiaodi >> Actually, I think just about all the rest of the precedence rules “make >> sense” intuitively: >> >> `a | b == c % d` >> `a < b ? c : d * e` >> `a ?? b - c` >> `a...b+c` >> >> These all do what they ought to, and of course assignment naturally has >> low precedence. Really the only confusing ones are operators that “seem >> like peers” but actually have different precedences. Namely the two groups >> I mentioned: logical operators and bitwise operators. >> >> @Daniel >> Making it easy to write code that is unclear to other people who read it, >> is an explicit anti-goal for Swift. >> > > 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. >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
