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

[Jacob Bandes-Storch]

On Wed, Sep 7, 2016 at 10:02 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

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

Both of these actually seem to make pretty careful use of parentheses in
expressions with mixed-precedence infix operators. In the former, I find
only a small handful of cases where & is mixed with +, *, or / — seemingly
the minority.


>
> 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 would think (hope) that any removals could easily yield automatic
migrations by adding parens where they were previously implied. I would
only be concerned with the possibility that such a migration would affect
type-checking speed (an area that already needs improvement, and can be
exacerbated by large expressions).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160907/f2ec5804/attachment.html>