[swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu]

I'm not sure how you're coming up with "domain areas". Ranges have numbers
as bounds; those are typically computed by arithmetic.

Virtually the entire stdlib exists to support language features; all other
facilities found in other languages' "standard library" are in Foundation.

As I mentioned, theoretical justifications have no sway with me. Show me
how a real user error is averted by such a change. I see none here; thus, I
disagree with the change.
On Tue, Aug 2, 2016 at 14:45 Anton Zhilin <antonyzhilin at gmail.com> wrote:

> 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>
>>>> 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/84ccaacb/attachment.html>