[swift-evolution] [Discussion] Breaking precedence

Anton Zhilin antonyzhilin at gmail.com
Tue Aug 2 14:13:27 CDT 2016


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/34d356ce/attachment.html>


More information about the swift-evolution mailing list