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

[Xiaodi Wu]

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 <xiaodi.wu at gmail.com> 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 <
> 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/56645ef9/attachment.html>