[swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu]

Let me give you theoretical basis for why I'm +0.5 on branching off binary
operators but not these other ones. Félix is absolutely right that `a << b
/ c` mixes two things. It's not merely that they're in two "different"
domains. It's that these two operators take the same values of the same
type and operate on them in fundamentally disparate ways.

This is a bad way of phrasing it, I know--let me try to clarify: the
operator `<<` operates on an integer as a fixed-length collection of bits;
the operator `/` operates on an integer as a number, an element in the set
of all integers. The practical consequence is that overflow behavior can be
subtly different; the overflow behavior of << is 'obvious' if you're
thinking about an integer as a fixed-length collection of bits but
surprising if you think of it as an integer being multiplied by an exponent
of two. Thus, it is best to separate operators that work on integers as a
collection of bits from the other numeric operators.

In no other of your proposed branches do I find the same fundamental
conflict.

On Tue, Aug 2, 2016 at 3:14 PM, Anton Zhilin <antonyzhilin at gmail.com> wrote:

> 2016-08-02 23:06 GMT+03:00 Xiaodi Wu <xiaodi.wu at gmail.com>:
>
>> 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.
>
>
> Okay, I'm creating a proposal for branching off binary operators, and
> after that I'll try to do a separate proposal for my crazy ideas :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160802/4f79e69c/attachment.html>