On Wed, Sep 7, 2016 at 11:48 PM, Jacob Bandes-Storch <[email protected]> wrote:
> On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu <[email protected]> wrote: > >> This suggestion has been pitched earlier and I've expressed my opinion in >> those earlier threads, but I'll repeat myself here: >> >> I'm hugely opposed to such changes to the precedence table. Those of us >> who work with bitwise operators on a regular basis have memorized their >> precedence in Swift (and other languages) and rely on such precedence to >> write readable, correct code without excessively nested parentheses. >> > > Could you point me towards some examples of such code? I don't write it > very often, so I don't feel I can really evaluate this. (This seems > analogous to the "terms of art" categorization from the API Design > Guidelines threads.) Much of the code I would normally write using bitwise > operators has been replaced with the SetAlgebra protocol methods provided > on OptionSet types. > Gladly. These (which cannot be copied verbatim into Swift, as C operator precedences are different): https://graphics.stanford.edu/~seander/bithacks.html Lest you think I'm giving you a C example because I don't actually use such things in Swift, here's me using some of these: https://github.com/xwu/FlowKit/blob/master/Source/BitVector.swift (Note that this specific example will soon be obsolete with new integer protocols.) Any change here would break existing, carefully constructed code, punishing >> those who *have* put in the effort to learn the precedence table. To any >> other user of Swift, it should come as no surprise that operators *have* >> precedence and associativity, and it is not such a burden for a user either >> to memorize or to consult a table for these properties when they are unsure >> . >> > >> There is no way whatsoever to use intuition to arrive at the exact >> precedence of `??`, or `as`, or `&&`, or `||`, or `&`, or `|`, or `^` or >> `<<`, or `>>`, and there will be no relative precedence that will prove >> intuitive to all. (That said, there is a rational basis for the relative >> precedence of `&`, `|`, and `^` to each other.) If you believe this >> situation to be problematic, then you must conclude that we should remove >> relative precedence between any operators except perhaps the basic >> arithmetic operators `+`, `-`, `*`, `/`. >> > > I hadn't really noticed until now that && and || have a defined ordering, > and can be mixed. These are operators I *do* use regularly, and mixing them > still makes me uncomfortable / seems unclear. Clang provides a warning for > this: -Wlogical-op-parentheses. > > I have a hard time seeing why the bitwise and arithmetic operators should > belong to the same set of precedence groups, such that & and * are BOTH > stronger than + and |. Even if some people are more acquainted with the > bitwise operators' precedences, as you say, why should & be stronger than > + ? Why should * be stronger than | ? > Just like << is a "close cousin" of exponentiation, & is a multiplication-like operator and ^ and | are addition-like operators on Boolean rings. To quote from previous messages in the older thread (from Felix Cloutier and Steve Canon): On Aug 2, 2016, at 12:18 AM, Félix Cloutier via swift-evolution < > [email protected]> wrote: > I disagree. The binary operators have properties that are comparable to > arithmetic operators, and their precedence is easy to define as such. & > has multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has > addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has > subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their > precedences are set accordingly (& is multiplicative, | and ^ are additive). > <extreme pedantry> > `^` is actually the *addition* operator on Boolean rings[1]. `x | y` > corresponds to the Boolean ring operation `x + y + xy`, which is definitely > “addition-like” but isn’t addition. > </extreme pedantry> > Otherwise, spot on. > – Steve > [1] Of course, it’s *also* the subtraction operator, because `x = -x` for > all members `x` of a Boolean ring (https://en.wikipedia.org/ > wiki/Boolean_ring), but one usually calls it “addition". > > How about this? > > [image: Inline image 3] > > (Personally, I'm comfortable with BitwiseShift being stronger than both > the other bitwise and the arithmetic operators, because it's a close cousin > of exponentiation.) > > >> This line of reasoning would be a huge U-turn from the direction of >> Swift, which after all just revised the syntax with which custom operator >> precedence is defined. Such a feature would be totally out of place in a >> language where operators other than those for basic arithmetic are not >> supposed to have precedence relations with each other. >> >> (Of course, the relative precedence of arithmetic operators is in some >> ways arbitrary as well, though it is inherited from math that everyone >> knows. How did you learn it in the first place? You memorized it.) >> >> > (from a later email) > > The promise of Swift 3 was that going forward, only essential >> source-breaking changes would occur; here, nothing about operators has >> changed since version 1, yet all of a sudden we are considering how to >> fundamentally alter how they work. Existing code *will break*, and >> sometimes silently, if such changes are made. > > > How could the breakage possibly be silent for a change like this? I'm not > proposing to add any new precedence relationships, just to remove/separate > existing ones. > The proposals include both breaking precedence relations and changing them; changing them will essentially always cause silent changes in existing code. Removing relations won't; however, it will necessitate sometimes difficult migrations, as formulas are complicated. I have, I think, a simple but effective argument in defense of the current scheme of operator precedences, but since it's midnight here, I'll let others chime in and return to the discussion later.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
