<div dir="ltr">I was asking about only bitwise operators, but the reply was more general. One reply from Chris Lattner:<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im" style="font-size:13px">> On Feb 13, 2016, at 6:32 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></span><span class="im" style="font-size:13px">><br></span><span class="im" style="font-size:13px">> Not sure if this is intentional, a bug, and/or a topic for evolution:<br></span><span class="im" style="font-size:13px">><br></span><span class="im" style="font-size:13px">> In Swift, <span class="">bitwise</span> <span class="">operators</span> seem to have a different precedence in<br></span><span class="im" style="font-size:13px">> relation to other <span class="">operators</span> than they do in (all other?) C-family<br></span><span class="im" style="font-size:13px">> languages, at least per documentation.</span><span class="im" style="font-size:13px"><br></span><span style="font-size:13px">Yep, this is true, and this is intentional. Swift has a greatly simplified and rationalized set of precedences, and yes, that means they differ from C.</span></blockquote><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 15, 2016 at 1:46 PM, Saagar Jha <span dir="ltr"><<a href="mailto:saagarjha28@gmail.com" target="_blank">saagarjha28@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span class=""><div dir="ltr">On Wed, Jun 15, 2016 at 11:36 AM Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha <span dir="ltr"><<a href="mailto:saagarjha28@gmail.com" target="_blank">saagarjha28@gmail.com</a>></span> wrote:<br></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes. They’re all operators we know about already, and the same argument applies. Just like you wouldn’t change + to have a higher precedence than *, bitwise operators already have their own, uniform precedences. I can’t see any reason not to have one, other than confusion from those who aren’t completely sure how they function-in which case they’re better of taking a look at the docs (or Quick Help, as another thread suggests) to learn how they work.</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>FYI, the relative precedence of arithmetic and bitwise operators is not the same across languages in the C family. Here, Swift diverges from C and resembles Go. I raised this point some time ago and was told in no uncertain terms by the core team that it was intentional and that they were satisfied with the result.</div></div></div></div></blockquote><div><br></div></span><div>Is the core team talking only for bitwise operators or all of them?</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин <<a href="mailto:antonyzhilin@gmail.com" target="_blank">antonyzhilin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What do you think about arithmetic and bitwise operators? Arithmetic and casting? Should they have defined precedence?<div><br></div><div>- Anton</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-15 21:17 GMT+03:00 Saagar Jha <span dir="ltr"><<a href="mailto:saagarjha28@gmail.com" target="_blank">saagarjha28@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We’ve talked about how expressions like `a + b * c / d` aren’t ambiguous because they are borrowed, in this case from math. The same thing applies to the ternary conditional: `a ? b : c + x + y`-it too is borrowed (from the C-type languages) and behaves likewise. There is no need for parentheses-the only people who will think this is ambiguous is those who haven’t been introduced to it before. IMHO, requiring parentheses would be <i>more</i> ambiguous because you’re breaking precedent, people already know how it should work, without parentheses. Forcing them to use it breaks their prior knowledge. We don’t need to hand-hold people who <i>know</i> how it works. For those who don’t know, it’s a simple matter of reading it up (which they would be doing anyways to learn about it!)<div><br></div><div>As for nil coalescing, it’s visually similar to the ternary operator and as such has similar behavior. Having a reminder in the Swift guide about its precedence should be enough, once users have learned it they don’t need to be reminded every time they use it through a warning.<div><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe wise to wait to see if that proposal is accepted. FWIW, my last interaction with the core team on operator precedence suggested that they believed that they had arrived at the correct relative precedence values and were not receptive to changing them.<br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 15, 2016 at 12:54 Антон Жилин <<a href="mailto:antonyzhilin@gmail.com" target="_blank">antonyzhilin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I wonder if it's worth it to start a new thread right now.<div>We could start discussing, what precedence relationships between opeartors should be, even *before* that proposal is accepted.</div><div>If it's rejected though, that discussion is going to trash bin.</div><div><br></div><div>- Anton</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-15 19:52 GMT+03:00 Антон Жилин <span dir="ltr"><<a href="mailto:antonyzhilin@gmail.com" target="_blank">antonyzhilin@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Back to associativity, I see nothing wrong with what a ?? b ?? c does. Analogous constructions are found in Ruby, for example. Right associativity exists so that we can do lazy evaluation, computing fallback values only when required. Nothing terrible, again.<div><br></div><div>- Anton</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-15 19:15 GMT+03:00 Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>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>> 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></span><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"><div><div>
<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><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>
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><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><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><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></div><div><div><div><div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
</div></div><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>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div></div></div><span><font color="#888888"><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">-Saagar Jha</div></div>
</font></span></blockquote></div><br></div>
</blockquote></div></div></div></div></div><span><font color="#888888"><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">-Saagar Jha</div></div>
</font></span></blockquote></div></div></div></blockquote></div></div></div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">-Saagar Jha</div></div>
</font></span></blockquote></div><br></div></div>