<div dir="ltr"><span style="font-size:12.8px;white-space:pre-wrap">This suggestion has been pitched earlier and I've expressed my opinion in those earlier threads, but I'll repeat myself here:</span><div><span style="font-size:12.8px;white-space:pre-wrap"><br></span></div><div><span style="font-size:12.8px;white-space:pre-wrap">I'm hugely opposed to such changes to the precedence table. </span><span style="font-size:12.8px;white-space:pre-wrap">Those of us who work with bitwise operators on a regular basis have memorized their precedence in Swift (and other languages) and rely on such precedence to write readable, correct code without excessively nested parentheses. Any change here would break existing, carefully constructed code, punishing those who *have* put in the effort to learn the precedence table. To any other user of Swift, it should come as no surprise that op</span><span style="font-size:12.8px;white-space:pre-wrap">erators *have* precedence and associativity, and it is not such a burden for a user either to memorize or to consult a table for these properties when they are unsure</span><span style="font-size:12.8px;white-space:pre-wrap">.</span></div><div><span style="font-size:12.8px;white-space:pre-wrap"><br></span></div><div><span style="font-size:12.8px;white-space:pre-wrap">There is no way whatsoever to use intuition to arrive at the exact precedence of `??`, or `as`,</span><span style="font-size:12.8px;white-space:pre-wrap"> or `&&`, or `||`, </span><span style="font-size:12.8px;white-space:pre-wrap">or `&`, or `|`, or `^` or `<<`, or `>>`, and there will be no relative precedence that will prove intuitive to all. (That said, there is a rational basis for the relative precedence of `&`, `|`, and `^` to each other.) </span><span style="font-size:12.8px;white-space:pre-wrap">If you believe this situation to be problematic, then you must conclude that we should remove relative precedence between any operators except perhaps the basic arithmetic operators `+`, `-`, `*`, `/`. </span><span style="font-size:12.8px;white-space:pre-wrap">This line of reasoning would be a huge U-turn from the direction of Swift, which after all just revised the syntax with which custom operator precedence is defined. Such a feature would be totally out of place in a language where operators other than those for basic arithmetic are not supposed to have precedence relations with each other.</span></div><div><span style="font-size:12.8px;white-space:pre-wrap"><br></span></div><div><span style="font-size:12.8px;white-space:pre-wrap">(Of course, the relative precedence of arithmetic operators is in some ways arbitrary as well, though it is inherited from math that everyone knows. How did you learn it in the first place? You memorized it.)</span></div><div><br></div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 5, 2016 at 2:47 PM, Erica Sadun via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>At this point, I'm not sure whether this is an -evolution question or a -dev question. The latter would be much easier to work on at this time and could potentially be postponed to a dot release. I know that any conversation not directly related to 3.0 right now is a Bad Thing. </div><div><br></div><div>And I suspect that Steven C is probably the right person to know about wrangling precedence and existing standards.</div><div><br></div><div>-- E</div><div><br></div><br><div><blockquote type="cite"><div>On Sep 5, 2016, at 12:30 AM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank">jtbandes@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Now you've gotten me thinking about precedence of other operators too.<div><br></div><div>Since ?? is prone to causing confusion in either direction (cf. your example and my example), it could be put in its own group whose relation to the numeric operators is intentionally undefined (thus requiring parens).</div><div><br></div><div>I don't know about other folks, but I'll certainly get confused if & and | and ^ are mixed. What if we removed their relation to each other (requiring parens when mixing them)?</div><div><br></div><div><span><proposed-precedence.png></span><br></div><div><br></div><div>For comparison (ha), here's what we have today:</div><div><br></div><div><span><current-precedence.png></span><br></div><div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div>Jacob<br></div></div></div></div><div><div class="gmail-h5">
<br><div class="gmail_quote">On Sat, Sep 3, 2016 at 10:20 PM, Erica Sadun <span dir="ltr"><<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div>On Sep 3, 2016, at 10:15 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank">jtbandes@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Perhaps-conversely, what should this code do?<div><br></div><div> let nextIndex = foundIndex ?? lastIndex + 1</div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div>Jacob<br></div></div></div></div></div></div></div></blockquote><div><br></div></span>It's a good counter example. And there's no optional-associative option.</div><span><font color="#888888"><div><br></div><div>-- E</div></font></span><span><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra">
<br><div class="gmail_quote">On Sat, Sep 3, 2016 at 9:05 PM, Erica Sadun via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Given: `<font face="Menlo">let x = Optional(3)</font>` then<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:menlo">`let y = 5 + x ?? 2` </span>will not compile</div></blockquote><div>but </div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="Menlo">`let y = 5 + (x ?? 2)` </font>will.</div></blockquote><div><br></div><div>Should <font face="Menlo">NilCoalescingPrecedence</font> be raised? The current operator precedence chain is:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font face="Menlo">BitwiseShiftPrecedence > MultiplicationPrecedence > AdditionPrecedence > RangeFormationPrecedence > CastingPrecedence > NilCoalescingPrecedence > ComparisonPrecedence > LogicalConjunctionPrecedence > LogicalDisjunctionPrecedence > TernaryPrecedence > AssignmentPrecedence > FunctionArrowPrecedence > [nothing]</font></div></div></blockquote><div><br></div><div>It seems to me that `<font face="Menlo">NilCoalescingPrecedence</font>` should probably be higher than `<font face="Menlo">MultiplicationPrecedence</font>` and possibly higher `<font face="Menlo">BitwiseShiftPrecedence</font>` as its job is to produce an unwrapped value that can then be operated upon.</div><div><br></div><div>I think <font face="Menlo">CastingPrecedence</font> should be even higher because</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:menlo">`expression as? T ?? fallback value`</span></div></blockquote><div>should be parsed as</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:menlo">`(expression as? T) ?? (fallback value)`</span></div></blockquote><div><br></div><div>I apologize profusely because I know this is beyond last minute,</div><div><br></div><div>-- E</div><div><br></div></div><br>______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote></div><br></span></div></blockquote></div><br></div></div></div></div></div>
</div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div></div></div></div></div>