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

[Xiaodi Wu]

On Wed, Sep 7, 2016 at 11:48 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
wrote:

> 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.
>

Gladly. These (which cannot be copied verbatim into Swift, as C operator
precedences are different):
https://graphics.stanford.edu/~seander/bithacks.html

Lest you think I'm giving you a C example because I don't actually use such
things in Swift, here's me using some of these:
https://github.com/xwu/FlowKit/blob/master/Source/BitVector.swift

(Note that this specific example will soon be obsolete with new integer
protocols.)

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 |  ?
>

Just like << is a "close cousin" of exponentiation, & is a
multiplication-like operator and ^ and | are addition-like operators on
Boolean rings. To quote from previous messages in the older thread (from
Felix Cloutier and Steve Canon):

On Aug 2, 2016, at 12:18 AM, Félix Cloutier via swift-evolution <
> swift-evolution at swift.org> wrote:
> I disagree. The binary operators have properties that are comparable to
> arithmetic operators, and their precedence is easy to define as such. &
> has multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has
> addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has
> subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their
> precedences are set accordingly (& is multiplicative, | and ^ are additive).
> <extreme pedantry>
> `^` is actually the *addition* operator on Boolean rings[1].  `x | y`
> corresponds to the Boolean ring operation `x + y + xy`, which is definitely
> “addition-like” but isn’t addition.
> </extreme pedantry>
> Otherwise, spot on.
> – Steve
> [1] Of course, it’s *also* the subtraction operator, because `x = -x` for
> all members `x` of a Boolean ring (https://en.wikipedia.org/
> wiki/Boolean_ring), but one usually calls it “addition".



>
> 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.
>

The proposals include both breaking precedence relations and changing them;
changing them will essentially always cause silent changes in existing
code. Removing relations won't; however, it will necessitate sometimes
difficult migrations, as formulas are complicated.

I have, I think, a simple but effective argument in defense of the current
scheme of operator precedences, but since it's midnight here, I'll let
others chime in and return to the discussion later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160908/031d1c92/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/20160908/031d1c92/attachment.png>