[swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu]

That's an excellent point, actually. Would there be downsides not yet
considered?

On Tue, Aug 2, 2016 at 11:03 Félix Cloutier <felixcca at 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.wu at gmail.com> a écrit :
>
> 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/6a45eabc/attachment.html>