[swift-evolution] [Discussion] Breaking precedence

Xiaodi Wu xiaodi.wu at gmail.com
Tue Aug 2 13:56:12 CDT 2016

I can sort of see what this is getting at, but I simply have no way of
evaluating whether it's sensible or not without actual examples in code.
This is, again, a more expansive change than discussed. I'd be interested
in seeing your write-up on separating arithmetic and bitwise/bitshift
operators :)

On Tue, Aug 2, 2016 at 1:36 PM, Anton Zhilin <antonyzhilin at gmail.com> wrote:

> 2016-08-02 21:09 GMT+03:00 Nevin Brackett-Rozinsky <
> nevin.brackettrozinsky at gmail.com>:
>> @Xiaodi
>> Actually, I think just about all the rest of the precedence rules “make
>> sense” intuitively:
>> `a | b == c % d`
>> `a < b ? c : d * e`
>> `a ?? b - c`
>> `a...b+c`
>> These all do what they ought to, and of course assignment naturally has
>> low precedence. Really the only confusing ones are operators that “seem
>> like peers” but actually have different precedences. Namely the two groups
>> I mentioned: logical operators and bitwise operators.
>> @Daniel
>> Making it easy to write code that is unclear to other people who read it,
>> is an explicit anti-goal for Swift.
> Here's another possible plan:
> https://gist.github.com/Anton3/e00026409a6f948ca3ba41acf24e9672
> There is a base line of "core", control-like operators, which everyone
> must know. "Applied" operators are branched off them. For example, Ternary,
> Comparison or Casting can be selected as base for a new mini-tree of
> related operators.
> Following this scheme, there are at least 3 "applied" domains with
> operators: arithmetic, bitwise and range formation. You can see result in
> the gist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160802/a0f41a1b/attachment.html>

More information about the swift-evolution mailing list