[swift-evolution] [Discussion] Breaking precedence

Anton Zhilin antonyzhilin at gmail.com
Tue Aug 2 16:41:23 CDT 2016

Here is the proposal draft:

Motivation will be the most difficult section here.

2016-08-02 23:30 GMT+03:00 Xiaodi Wu <xiaodi.wu at gmail.com>:

> 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.

And that argumentation seems insufficient to me. Assuming that everyone
knows precedence table, 'a << b / c` should not be ambiguous. I'd argue
that it's easy to understand that << operation will overflow here and /
will not.
Instead, I suggest that these operations are so different that any
precedence relationship between them is meaningless (another wording of
explanation with domains).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160803/b421aa73/attachment.html>

More information about the swift-evolution mailing list