<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> If precedence between two operators is undefined, we cannot omit<br>
> parentheses.<br>
<br></span>
Hm.. Probably the initial problem could be solved with this? I.e. if we'll have *no* defined precedence between math operators and between ?? and between ?: (and probably something else?) ?<br></blockquote><div><br></div><div>Sorry, I don't see it. The initial question was about chaining of ?? operators. That's a problem with expectations about associativity and not about precedence, right?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As for rules of precedence, I think it is really not important what precedence will be assigned for ??/?: as in any case IMO most devs will not remember this for sure in situation when one need to write/read such complex expression.<br>
<br>
For me, probably I have some extreme opinion: if we have a mix of operators from different domains (math and ?? for example) we need parentheses to exclude any kind of ambiguity.<span class=""><br>
<br>
On 15.06.2016 17:53, Антон Жилин wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Nice points, I also think that unless operators are from the same domain,<br>
more parentheses is better.<br>
Other than that, what rules do we need? I can name these:<br>
1. Assignment operators have lower precedence than most operators<br>
2. Arithmetics has higher precedence than comparative and logical<br>
operators. I don't think that ?? belongs to arithmetics, it's more like<br>
control flow.<br>
3. Unary operators obviously have higher precedence than everything<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I didn't read se-0077 in details, so have no opinion. Probably you can<br>
</blockquote>
describe main ideas of it here in two words.<br>
Replace numeric precedence with precedence relationships between pairs of<br>
operators. If precedence between two operators is undefined, we cannot omit<br>
parentheses.<br>
<br>
My thought was basically: "parentheses between some operators must be<br>
enforced by the language" <=> "SE-0077 is needed"<br>
<br>
- Anton<br>
<br>
2016-06-15 17:17 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>>>:<div><div class="h5"><br>
<br>
<br>
On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote:<br>
<br>
`b + c * d / e` is not, obviously.<br>
<br>
<br>
obviously, for math operators it seems like we don't need any<br>
clarifications<br>
<br>
`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<br>
looks<br>
like a mess with ? and : operators).<br>
<br>
<br>
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.<br>
<br>
`a ?? x + y + z` -- maybe. If not for analogies with || and && and<br>
knowing<br>
about @autoclosure, I'd say that priority of ?? should be very high.<br>
<br>
<br>
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<br>
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<br>
beginners) do remember the the correct precedence in such expressions<br>
and in most cases will not make a bug and so we should not require the<br>
parentheses. Imagine how each such expression will be crystal clear<br>
about the order of processing in *any* Swift source code you could find<br>
anywhere. IMO this will be great advantage of the language.<br>
<br>
Now that I think about it, if job of SE-0077 could be done with a<br>
linter,<br>
then... do we still need it?<br>
<br>
<br>
I didn't read se-0077 in details, so have no opinion. Probably you can<br>
describe main ideas of it here in two words.<br>
<br>
<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>
<mailto:<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>><br></div></div>
<mailto:<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a> <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<br>
accepted,<br>
we will<br>
be able to make omission of parentheses an error in<br>
ambiguous cases.<br>
<br>
- Anton<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><br></span>
<mailto:<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>>><span class=""><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>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<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><br>
<br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
_______________________________________________<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>
</div></div></blockquote></div><br></div></div>