[swift-evolution] [Discussion] Breaking precedence
antonyzhilin at gmail.com
Tue Aug 2 14:45:14 CDT 2016
If operator <+> is used in one domain area, and operator <-> is used in
another domain area, then we should not make everyone keep in mind both
domain areas simultaneously.
Another explanation: operator ... does not belong to "core", "control"
operators, it belongs to Ranges part of standard library. Likewise, +
operates on numbers. Therefore they should not have precedence relationship.
Yet another explanation: I believe that optionals and booleans are a lot
more fundamental in Swift than ranges. Ranges don't have any support in
language itself, they belong to standard library.
2016-08-02 22:19 GMT+03:00 Xiaodi Wu <xiaodi.wu at gmail.com>:
> 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>
>> Here's another possible plan:
>>>> 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...
More information about the swift-evolution