[swift-evolution] Standard operator precedence

[Xiaodi Wu]

Yes, but not enough to claim limited resources needed for pressing matters.
It's not a feature anyone would clamor for, more a product of the foolish
consistency hobgoblin. Rationale: it is possible in JavaScript (for
instance) to evaluate true * true, but not in Swift. [I'm aware that
implicit casting is taking place in JavaScript, and that the return type
isn't a Boolean.] It comes into play in exactly one scenario I can think of:

Student: "Why is & a multiplicative operation?"
Teacher: "Well, because for two bits A and B, A & B == A * B."
Student: "That's interesting, let me try it with the only type I know that
represents a single bit of data."
[At this point the student should, IMO, be able to actually evaluate A * B
where A and B are booleans.]

Analogous rationale for defining &+ and &- on booleans.

On Mon, Feb 15, 2016 at 12:20 PM Chris Lattner <clattner at apple.com> wrote:

> On Feb 14, 2016, at 10:25 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> Some further study has been helpful. Am I close to the mark in answering
> my own question?
>
> - Further reading shows that Swift's rationalized operator precedence
> levels broadly align with those of Erlang and Go. (However, those languages
> also seem to lack documentation on how they arrived at this set of
> precedence levels.)
>
> - It is quite evident why << is considered exponentiative.
>
> - Dennis Ritchie has explained <http://www.lysator.liu.se/c/dmr-on-or.html>
> why & has lower precedence than == in C, and why in hindsight that is
> better off changed. This change has been implemented in Swift/Go/Erlang and
> also in other languages like Python.
>
> - & is considered multiplicative because for two bits A and B, A & B == A
> * B.
>
> - ^ and | should have equal precedence to - and +, respectively, by
> analogous reasoning.
>
> - It also happens to be rational for & to have higher precedence than | by
> analogy with && and ||.
>
>
> Yep, this is all right.
>
> It's a bit of a bummer, if this line of reasoning was indeed used in
> arriving at these operator precedence levels, that Swift will not allow
> evaluation of true * true (etc.) without casting. I would expect true &
> true == true * true.
>
>
> I’m not sure what you mean here.  You want multiplication defined on
> booleans?
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160215/8f3e4526/attachment.html>