> On Aug 2, 2016, at 11:09 AM, Nevin Brackett-Rozinsky > <nevin.brackettrozin...@gmail.com> wrote: > > @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. >
Again, one’s “easy” might not apply to others, it’s easy *to him/her*. For people who intuitively pick out these precedences, extra parens is just noise that makes them second guess their understandings. The goal we should pursue is *clarity*. Today, if one wants to emphasize the precedence, they can add parens anyways: ` a || (b && c)`. But if we make `a || b && c` have different meaning, that makes the code really really unclear (to the rest of us, who have assumptions about how precedences from our backgrounds) and will be a source for bugs. Assuming neither option is objectively better than the other, you need to convince us why the change is worth this cost. > Nevin > > > On Tue, Aug 2, 2016 at 1:42 PM, Xiaodi Wu <xiaodi...@gmail.com > <mailto:xiaodi...@gmail.com>> wrote: > This is an expansive argument you advance. Should users be expected to learn > *any* rules of precedence beyond those of basic arithmetic? It would seem > that you are arguing no. Yet Swift just went through an arduous redesign to > permit--nay, improve--exactly that. > > On Tue, Aug 2, 2016 at 12:30 Nevin Brackett-Rozinsky > <nevin.brackettrozin...@gmail.com <mailto:nevin.brackettrozin...@gmail.com>> > wrote: > Speaking for myself, I will *never* remember which of `&&` and `||` has > higher precedence. I think of them as peers, so I always use parentheses > around them, and whenever I read code that mingles them without parentheses > its meaning is *unclear* to me. > > One of Swift’s main goals is clarity at the point of use. After all, code is > read far more often than it is written. To me, an expression like `a && b || > c && d` is not clear when I read it. > > The same goes for bitwise operators: I view them as peers. I do not think of > them as “additive” or “multiplicative” (and definitely not “subtractive”), so > code that relies on their precedences will always send me scrambling to look > up which comes first. > > Certainly something like `a + b | c & d - e * f ^ g` is meaningless to me > without parentheses. > > Nevin > > > On Tue, Aug 2, 2016 at 12:08 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > That's an excellent point, actually. Would there be downsides not yet > considered? > > > On Tue, Aug 2, 2016 at 11:03 Félix Cloutier <felix...@yahoo.ca > <mailto:felix...@yahoo.ca>> wrote: > These expressions mix two types of logic that have different implications. > For instance, `a * 16` and `a << 4` are "mostly equivalent", except that `a * > 16` will crash on overflow. In these cases, I find that grouping provides > some visual insulation that groups off the somewhat subtle differences. > > Félix > >> Le 2 août 2016 à 08:49:07, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> a écrit : >> >> On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier <felix...@yahoo.ca >> <mailto:felix...@yahoo.ca>> wrote: >> I don't think that "intuitive" or "non-intuitive" is what you'd be looking >> for. There is nothing intuitive about multiplications having a higher >> precedence than additions; it's just a matter of conventions. I'm not a >> maths expert (as Stephen showed, I didn't even give the right explanation to >> binary operators!), but it seems to me that there could well be a parallel >> universe in which additions have precedence over multiplications without >> other serious implications. >> >> And as it happens, a majority of people don't know that there is one for >> binary operators. I believe that the right question should be: do we want to >> pretend that this convention doesn't exist, to the benefit of people who >> don't know about it, and the detriment of those who do? Also, do we want to >> break it for && and || too? >> >> I think that the biggest use case for binary operators in other languages >> are flags, and in Swift we treat these as collections. I'd venture that &, | >> and ^ would show up about as frequently as UnsafePointers and the like. It >> seems to me that Swift's approach has been to make things easy by default >> without locking away the power tools, and my personal expectation is that if >> you have to write code that has binary operators despite everything else >> that Swift has for you, you can be bothered to learn a precedence rule. >> >> That said, one thing that I could definitely get behind is breaking >> precedence between binary operators and arithmetic operators. I don't think >> that it makes sense to write something like "a & b / c". Looking at my code, >> the only place where I needed to mix binary operators and arithmetic >> operators were `a & (a - 1)` (results in 0 if a is a power of two), and that >> one needs parentheses anyway. >> >> Although here, your same argument applies. If you need to write `a & b / c`, >> then you can be bothered either to learn or look up a table, or you can just >> put in the parenthesis yourself. Likewise, if you're a reader of the code, >> it's highly likely that this is a complex formula anyway; you can either >> know the relative precedence or look it up, but that's the *least* of your >> worries in terms of what it will take to understand that code. I see no >> reason to force parentheses unless it actually prevents user error. >> >> >> >> Félix >> >>> Le 2 août 2016 à 02:29:41, Anton Zhilin <antonyzhi...@gmail.com >>> <mailto:antonyzhi...@gmail.com>> a écrit : >>> >>> 2016-08-02 7:18 GMT+03:00 Félix Cloutier <swift-evolution@swift.org >>> <mailto:swift-evolution@swift.org>>: >>> 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). >>> >>> The same applies to && and ||. Bit shifts are exponentiative. >>> >>> I believe that such way of thinking is non-intuitive. In C, bitwise >>> operators are not intervened by any others, except for comparison operators >>> (agreed, it was a mistake). We now have possibilities to do so in Swift, >>> even better. I suggest to branch off right before AdditionPrecedence: >>> >>> RangeFormation < Addition < Multiplication >>> RangeFormation < BitwiseOr < BitwiseAnd < LogicalShift >>> >>> Another concern is NilCoalescing, which can be though to be semantically >>> similar to Ternary. And at the same time it looks like || and &&, which >>> would bring it between LogicalConjunction and Comparison. >>> Also, do Casting and RangeFormation stand where they should? >>> >>> Next, Ternary operator is unique. Noone would ever like to put operators in >>> this precedence group, because it would be confusing. Why not simplify our >>> model and say that ?: has lower precedence than all binary operators, >>> including Assignment? Unary > binary > ternary, sounds good? > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
