[swift-evolution] Standard operator precedence

[Dave Abrahams]

on Mon Feb 15 2016, Jordan Rose <swift-evolution at swift.org> wrote:

> A boolean is not a single bit of data in Swift, in the same way that
> "someIntegerValue & 1" cannot be used as a condition. There is a
> bijection between boolean values and integers with one bit set or
> cleared, but they are not the same type.
>
> (You can't use '&' on a Bool either, only '&&'. That does mean Swift
> has no non-short-circuiting boolean AND operation, but so far we
> haven't needed one.)

I don't know if that's strictly true, Jordan.  At least once upon a
time, the performance team was fond of replacing && with & for
performance reasons (to avoid branches).  I hope our optimizer has since
learned to do this for itself in all the cases that matter, though ;-)

> Jordan
>
>> On Feb 15, 2016, at 11:17, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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
>> <mailto:clattner at apple.com>> wrote:
>>> On Feb 14, 2016, at 10:25 AM, Xiaodi Wu
>>> <xiaodi.wu at gmail.com
>>> <mailto: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
>>> <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
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave