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 <[email protected]> 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 <[email protected]> wrote: > >> 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
