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 < [email protected]> 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 < > [email protected]> 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 <[email protected]> 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 <[email protected]> a écrit : >>> >>> On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier <[email protected]> >>> 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 <[email protected]> a >>>> écrit : >>>> >>>> 2016-08-02 7:18 GMT+03:00 Félix Cloutier <[email protected]>: >>>> >>>>> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
