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
