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

[Jacob Bandes-Storch]

On Mon, Sep 5, 2016 at 1: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.
>

Could you point me towards some examples of such code? I don't write it
very often, so I don't feel I can really evaluate this. (This seems
analogous to the "terms of art" categorization from the API Design
Guidelines threads.) Much of the code I would normally write using bitwise
operators has been replaced with the SetAlgebra protocol methods provided
on OptionSet types.

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 `+`, `-`, `*`, `/`.
>

I hadn't really noticed until now that && and || have a defined ordering,
and can be mixed. These are operators I *do* use regularly, and mixing them
still makes me uncomfortable / seems unclear. Clang provides a warning for
this: -Wlogical-op-parentheses.

I have a hard time seeing why the bitwise and arithmetic operators should
belong to the same set of precedence groups, such that & and * are BOTH
stronger than + and |.  Even if some people are more acquainted with the
bitwise operators' precedences, as you  say, why should & be stronger than
+ ? Why should * be stronger than |  ?

How about this?

[image: Inline image 3]

(Personally, I'm comfortable with BitwiseShift being stronger than both the
other bitwise and the arithmetic operators, because it's a close cousin of
exponentiation.)


> 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.)
>
>
(from a later email)

The promise of Swift 3 was that going forward, only essential
> source-breaking changes would occur; here, nothing about operators has
> changed since version 1, yet all of a sudden we are considering how to
> fundamentally alter how they work. Existing code *will break*, and
> sometimes silently, if such changes are made.


How could the breakage possibly be silent for a change like this?  I'm not
proposing to add any new precedence relationships, just to remove/separate
existing ones.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160907/08246ec1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bitwise-arithmetic-logical-distinctions.png
Type: image/png
Size: 73056 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160907/08246ec1/attachment.png>