[swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

[Xiaodi Wu]

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 <
swift-evolution at swift.org> 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 <jtbandes at gmail.com>
> 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 <erica at ericasadun.com> wrote:
>
>> On Sep 3, 2016, at 10:15 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
>> 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 <
>> swift-evolution at swift.org> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160905/de92ff98/attachment.html>