[swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu]

Re: ternary operators--this goes far beyond the boundaries of the
discussion you yourself started. Removing certain relative precedences so
that parentheses are required is one thing; *changing* relative precedences
is quite another. For me at least, the latter is an absolute nonstarter.
Every existing usage of the operator could potentially *silently* break.

As to removing certain precedences--the current Swift precedences are
rationally defensible. Perhaps anything you propose would be too, but
trading one rational scheme for another (at best) is not justification
enough for a source-breaking change. Instead, show me a scenario in which
you write something today that could plausibly do something other than what
it might look like, where forcing parentheses would fix the issue--i.e.
convince me a change would eliminate actual user errors--and I'm on board.
So far, I haven't seen one (even the "maybe" scenario above, a && b | c,
wouldn't work in Swift unless you defined custom operator functions
yourself, so there's no real possibility of a silent error).
On Tue, Aug 2, 2016 at 08:31 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> What's your evidence that it's non-intuitive? I literally use << for
> powers of 2, as I'm sure do many others. As in, 1 << 3 == 8. Do you have a
> better way of computing, say, 2^53?
>
> On Tue, Aug 2, 2016 at 04:29 Anton Zhilin <antonyzhilin at gmail.com> wrote:
>
>> 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/eb1252c6/attachment.html>