On Wed, Sep 7, 2016 at 10:02 PM, Xiaodi Wu <[email protected]> wrote:
> On Wed, Sep 7, 2016 at 11:48 PM, Jacob Bandes-Storch <[email protected]> > wrote: > >> On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu <[email protected]> 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).
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
