This suggestion has been pitched earlier and I've expressed my opinion in those earlier threads, but I'll repeat myself here:
I'm hugely opposed to such changes to the precedence table. Those of us who work with bitwise operators on a regular basis have memorized their precedence in Swift (and other languages) and rely on such precedence to write readable, correct code without excessively nested parentheses. Any change here would break existing, carefully constructed code, punishing those who *have* put in the effort to learn the precedence table. To any other user of Swift, it should come as no surprise that operators *have* precedence and associativity, and it is not such a burden for a user either to memorize or to consult a table for these properties when they are unsure. There is no way whatsoever to use intuition to arrive at the exact precedence of `??`, or `as`, or `&&`, or `||`, or `&`, or `|`, or `^` or `<<`, or `>>`, and there will be no relative precedence that will prove intuitive to all. (That said, there is a rational basis for the relative precedence of `&`, `|`, and `^` to each other.) If you believe this situation to be problematic, then you must conclude that we should remove relative precedence between any operators except perhaps the basic arithmetic operators `+`, `-`, `*`, `/`. This line of reasoning would be a huge U-turn from the direction of Swift, which after all just revised the syntax with which custom operator precedence is defined. Such a feature would be totally out of place in a language where operators other than those for basic arithmetic are not supposed to have precedence relations with each other. (Of course, the relative precedence of arithmetic operators is in some ways arbitrary as well, though it is inherited from math that everyone knows. How did you learn it in the first place? You memorized it.) On Mon, Sep 5, 2016 at 2:47 PM, Erica Sadun via swift-evolution < [email protected]> wrote: > At this point, I'm not sure whether this is an -evolution question or a > -dev question. The latter would be much easier to work on at this time and > could potentially be postponed to a dot release. I know that any > conversation not directly related to 3.0 right now is a Bad Thing. > > And I suspect that Steven C is probably the right person to know about > wrangling precedence and existing standards. > > -- E > > > On Sep 5, 2016, at 12:30 AM, Jacob Bandes-Storch <[email protected]> > wrote: > > Now you've gotten me thinking about precedence of other operators too. > > Since ?? is prone to causing confusion in either direction (cf. your > example and my example), it could be put in its own group whose relation to > the numeric operators is intentionally undefined (thus requiring parens). > > I don't know about other folks, but I'll certainly get confused if & and | > and ^ are mixed. What if we removed their relation to each other (requiring > parens when mixing them)? > > <proposed-precedence.png> > > For comparison (ha), here's what we have today: > > <current-precedence.png> > > Jacob > > On Sat, Sep 3, 2016 at 10:20 PM, Erica Sadun <[email protected]> wrote: > >> On Sep 3, 2016, at 10:15 PM, Jacob Bandes-Storch <[email protected]> >> wrote: >> >> Perhaps-conversely, what should this code do? >> >> let nextIndex = foundIndex ?? lastIndex + 1 >> >> Jacob >> >> >> It's a good counter example. And there's no optional-associative option. >> >> -- E >> >> >> On Sat, Sep 3, 2016 at 9:05 PM, Erica Sadun via swift-evolution < >> [email protected]> wrote: >> >>> Given: `let x = Optional(3)` then >>> >>> `let y = 5 + x ?? 2` will not compile >>> >>> but >>> >>> `let y = 5 + (x ?? 2)` will. >>> >>> >>> Should NilCoalescingPrecedence be raised? The current operator >>> precedence chain is: >>> >>> BitwiseShiftPrecedence > MultiplicationPrecedence > AdditionPrecedence > >>> RangeFormationPrecedence > CastingPrecedence > NilCoalescingPrecedence > >>> ComparisonPrecedence > LogicalConjunctionPrecedence > >>> LogicalDisjunctionPrecedence > TernaryPrecedence > AssignmentPrecedence > >>> FunctionArrowPrecedence > [nothing] >>> >>> >>> It seems to me that `NilCoalescingPrecedence` should probably be higher >>> than `MultiplicationPrecedence` and possibly higher ` >>> BitwiseShiftPrecedence` as its job is to produce an unwrapped value >>> that can then be operated upon. >>> >>> I think CastingPrecedence should be even higher because >>> >>> `expression as? T ?? fallback value` >>> >>> should be parsed as >>> >>> `(expression as? T) ?? (fallback value)` >>> >>> >>> I apologize profusely because I know this is beyond last minute, >>> >>> -- E >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >> >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
