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 <[email protected]> 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 <[email protected]>: > >> What's the benefit? Is there anyone confused by a...b+c? >> >> On Tue, Aug 2, 2016 at 14:13 Anton Zhilin <[email protected]> wrote: >> >>> 2016-08-02 21:56 GMT+03:00 Xiaodi Wu <[email protected]>: >>> >>>> 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 <[email protected]> >>>> 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 >>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
