<div dir="ltr">Nice points, I also think that unless operators are from the same domain, more parentheses is better.<div>Other than that, what rules do we need? I can name these:<div>1. Assignment operators have lower precedence than most operators</div><div>2. Arithmetics has higher precedence than comparative and logical operators. I don't think that ?? belongs to arithmetics, it's more like control flow.</div></div><div>3. Unary operators obviously have higher precedence than everything</div><div><br></div><div>> I didn't read se-0077 in details, so have no opinion. Probably you can describe main ideas of it here in two words.</div><div>Replace numeric precedence with precedence relationships between pairs of operators. If precedence between two operators is undefined, we cannot omit parentheses.</div><div><br></div><div>My thought was basically: "parentheses between some operators must be enforced by the language" <=> "SE-0077 is needed"</div><div><br></div><div>- Anton</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-15 17:17 GMT+03:00 Vladimir.S <span dir="ltr"><<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
`b + c * d / e` is not, obviously.<br>
</blockquote>
<br></span>
obviously, for math operators it seems like we don't need any clarifications<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
`a ? b : c + x + y` -- I'd also say not, because, well, it's ternary<br>
operator, the special case that everyone should know (otherwise it looks<br>
like a mess with ? and : operators).<br>
</blockquote>
<br></span>
Yes, it's ternary operator. But is it<br>
a ? b : (c + x + y)<br>
or<br>
(a ? b : c) + x + y<br>
<br>
IMO ambiguous.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
`a ?? x + y + z` -- maybe. If not for analogies with || and && and knowing<br>
about @autoclosure, I'd say that priority of ?? should be very high.<br>
<br>
</blockquote>
<br></span>
The same, is it<br>
a ?? (x + y + z)<br>
or<br>
(a ?? x) + y + z<br>
<br>
? I.e. I'm not asking, just show that the question is not if we know what does ?? mean, but how all the expression will be treated.<br>
<br>
IMO it's totally false assumption that most of developers(and poor beginners) do remember the the correct precedence in such expressions and in most cases will not make a bug and so we should not require the parentheses. Imagine how each such expression will be crystal clear about the order of processing in *any* Swift source code you could find anywhere. IMO this will be great advantage of the language.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now that I think about it, if job of SE-0077 could be done with a linter,<br>
then... do we still need it?<br>
</blockquote>
<br></span>
I didn't read se-0077 in details, so have no opinion. Probably you can describe main ideas of it here in two words.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
- Anton<br>
<br>
2016-06-15 16:00 GMT+03:00 Vladimir.S <<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a><br></span>
<mailto:<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>>>:<span class=""><br>
<br>
As I understand, the question is if<br>
<br>
`a ?? x + y + z`<br>
and<br>
`a ? b : c + x + y`<br>
(or `b + c * d / e`)<br>
<br>
an "ambiguous case" ?<br>
<br>
<br>
On 15.06.2016 15:42, Антон Жилин via swift-evolution wrote:<br>
<br>
It's tempting to mention SE-0077 in this context. If it's accepted,<br>
we will<br>
be able to make omission of parentheses an error in ambiguous cases.<br>
<br>
- Anton<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br></span>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<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/mailman/listinfo/swift-evolution</a><span class=""><br>
<br>
<br>
<br>
<br>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
<br>
</span></blockquote>
</blockquote></div><br></div>