[swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu]

What's the benefit? Is there anyone confused by a...b+c?
On Tue, Aug 2, 2016 at 14:13 Anton Zhilin <antonyzhilin at gmail.com> wrote:

> 2016-08-02 21:56 GMT+03:00 Xiaodi Wu <xiaodi.wu at gmail.com>:
>
>> 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:
>>
> 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.
>>>
>>
> Well, I don't suggest changing precedence relationships there (just
> removing some), so that should be on-topic, I guess?
>
> The main change I suggest over separating bitwise operators is separating
> RangeFormation, because it's a separate, "applied" operator domain. It is
> not control-structure-like, so it does not deserve to be in the main tree.
>
> Simplifying even more, I want to prohibit this:  a...b+c
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160802/19359bff/attachment.html>