<div dir="ltr">With the replacement, I would prefer just &quot;then-else&quot;, which would still clearly carry the meaning of low priority. But yes, this option was explicitly rejected. Unfortunately.<div><br></div><div>I also agree that changing the priority is not a solution. But how about removing priority?</div><div><br></div><div>The following expression:</div><div>`<span style="font-size:12.8px">s &lt;&lt; (x == 10) ? &quot;10&quot; : &quot;not 10&quot;`</span></div><div><span style="font-size:12.8px">Is currently parsed as</span></div><div><div class="gmail_extra"><span style="font-size:12.8px">`(</span><span style="font-size:12.8px">s &lt;&lt; (x == 10)) ? &quot;10&quot; : &quot;not 10&quot;`</span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px">With such a change, the compiler would make you add outer parentheses and find a bug, by the way:</span></div><div class="gmail_extra">`<span style="font-size:12.8px">s &lt;&lt; ((x == 10) ? &quot;10&quot; : &quot;not 10&quot;)`</span></div><div class="gmail_extra"><span style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8px">Should this apply to assignment operators?</span></div><div class="gmail_extra">`s += (x == 10) ? &quot;10&quot; : &quot;not 10&quot;  // error?`</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think such caveats of `?:` are worth creating a proposal, at least.</div><div class="gmail_extra"><span style="font-size:12.8px"><br></span><div class="gmail_quote">2016-09-03 14:21 GMT+03:00 Thorsten Seitz via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div>The problem you describe is not the priority of the ternary operator but that developers just assume a priority without checking (or learning) whether their assumption is correct. Changing the priority won&#39;t solve that problem, it would only shift the problem over to those developers assuming the other priority. Worse, it would create this problem for those developers knowing the correct priority, because they now have to relearn the new priority with the added difficulty of the priority being different from C.</div><div><br></div><div>I&#39;m not sure whether the problem really is one (other operators have priorities too, which have to be learned), but assuming for the moment that it is, a solution would be to replace the ternary operator with an if-expression: <b>if</b> condition <b>then</b> expr1 <b>else</b> expr2</div><div>This would enclose the condition between two keywords and thereby be free of misunderstandings.</div><div>Replacing the ternary operator is on the commonly asked changes list, though, and therefore requires new arguments/insights why a replacement would make sense. I think the possibly confusing priority has been discussed already in the past and therefore wouldn&#39;t count as new insight, though I&#39;m not quite sure.</div><div><br></div><div>-Thorsten </div></div></blockquote></div></div></div></div>