[swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu]

On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier <felixcca at 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 <antonyzhilin at gmail.com> a écrit :
>
> 2016-08-02 7:18 GMT+03:00 Félix Cloutier <swift-evolution at 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?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160802/37c0b269/attachment.html>