Likely relevant to this discussion, Chris Lattner's comment in the last thread about changing operator precedence (early August):
Some 2c to consider: > 1) Swift 4 is being designed with the ability to all us to make “source > changes" that don’t break existing source code. > 2) It is really important that we continue to polish the language to make > it great for the long term, so the spirit of your proposal is great to > explore. > 3) That said, any source breaking change needs to be *very* strongly > motivated. To make this change, you should find evidence of common bugs > that would be solved by this, evidence of actual user confusion in > practice, etc. > 4) Assuming all of the above works out, we still won’t be able to evaluate > the proposal until we have the exact details of how the “source stability” > model works. Until we have that model, we don’t know that this proposal > will be able to be covered by it. > On #4, I’m pretty certain that we will be fine, but until we have the > model nailed down, we procedurally can’t even have the formal review > period. In any case, you need to build a specific proposal with very > strong rationale first. :-) > -Chris On Mon, Sep 5, 2016 at 3:19 PM, Xiaodi Wu <[email protected]> wrote: > 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
