[swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu]

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>