Yes all good points--and very interesting history from Dave. Thanks all.<br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 15, 2016 at 1:47 PM Taras Zakharko <<a href="mailto:taras.zakharko@uzh.ch">taras.zakharko@uzh.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I think the teacher should just do a better job explaining group theory ;) Its perfectly consistent to treat * and & separately, because they de-facto interpret their arguments as different types. <div><br></div><div><div>— T<br><div><br><div><blockquote type="cite"></blockquote></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div><blockquote type="cite"><div>On 15 Feb 2016, at 20:17, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></blockquote></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div><blockquote type="cite"><div><div style="white-space:pre-wrap">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:<br><br>Student: "Why is & a multiplicative operation?"<br>Teacher: "Well, because for two bits A and B, A & B == A * B."<br>Student: "That's interesting, let me try it with the only type I know that represents a single bit of data."<br>[At this point the student should, IMO, be able to actually evaluate A * B where A and B are booleans.]<br><br>Analogous rationale for defining &+ and &- on booleans.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 15, 2016 at 12:20 PM Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Feb 14, 2016, at 10:25 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br><div>Some further study has been helpful. Am I close to the mark in answering my own question?<br><br>- 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.)<br><br>- It is quite evident why << is considered exponentiative.<br><br>- Dennis Ritchie has explained <<a href="http://www.lysator.liu.se/c/dmr-on-or.html" target="_blank">http://www.lysator.liu.se/c/dmr-on-or.html</a>> 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.<br><br>- & is considered multiplicative because for two bits A and B, A & B == A * B.<br><br>- ^ and | should have equal precedence to - and +, respectively, by analogous reasoning.<br><br>- It also happens to be rational for & to have higher precedence than | by analogy with && and ||.<br></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Yep, this is all right.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div>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.<br></div></blockquote></div></div><div style="word-wrap:break-word"><div></div><br><div>I’m not sure what you mean here. You want multiplication defined on booleans?</div></div><div style="word-wrap:break-word"><div><br></div><div>-Chris</div></div></blockquote></div></div></blockquote></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div><blockquote type="cite"><div>
_______________________________________________</div></blockquote></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div><blockquote type="cite"><div><br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div></div></div></div></blockquote></div>