[swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low
jtbandes at gmail.com
Wed Sep 7 23:48:38 CDT 2016
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
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 73056 bytes
Desc: not available
More information about the swift-evolution