I was asking about only bitwise operators, but the reply was more general. One reply from Chris Lattner:
> On Feb 13, 2016, at 6:32 AM, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > > > Not sure if this is intentional, a bug, and/or a topic for evolution: > > > > In Swift, bitwise operators seem to have a different precedence in > > relation to other operators than they do in (all other?) C-family > > languages, at least per documentation. > 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. On Wed, Jun 15, 2016 at 1:46 PM, Saagar Jha <[email protected]> wrote: > > On Wed, Jun 15, 2016 at 11:36 AM Xiaodi Wu <[email protected]> wrote: > >> On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha <[email protected]> >> wrote: >> >>> 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. >>> >> >> 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. >> > > Is the core team talking only for bitwise operators or all of them? > > >> >> >>> >>> On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин <[email protected]> >>> wrote: >>> >>>> What do you think about arithmetic and bitwise operators? Arithmetic >>>> and casting? Should they have defined precedence? >>>> >>>> - Anton >>>> >>>> 2016-06-15 21:17 GMT+03:00 Saagar Jha <[email protected]>: >>>> >>>>> 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 >>>>> *more* 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 *know* 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!) >>>>> >>>>> 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. >>>>> >>>>> >>>>> On Wed, Jun 15, 2016 at 11:00 AM Xiaodi Wu via swift-evolution < >>>>> [email protected]> wrote: >>>>> >>>>>> 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. >>>>>> On Wed, Jun 15, 2016 at 12:54 Антон Жилин <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I wonder if it's worth it to start a new thread right now. >>>>>>> We could start discussing, what precedence relationships between >>>>>>> opeartors should be, even *before* that proposal is accepted. >>>>>>> If it's rejected though, that discussion is going to trash bin. >>>>>>> >>>>>>> - Anton >>>>>>> >>>>>>> 2016-06-15 19:52 GMT+03:00 Антон Жилин <[email protected]>: >>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> - Anton >>>>>>>> >>>>>>>> 2016-06-15 19:15 GMT+03:00 Xiaodi Wu <[email protected]>: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> > If precedence between two operators is undefined, we cannot >>>>>>>>>> omit >>>>>>>>>> > parentheses. >>>>>>>>>> >>>>>>>>>> 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?) ? >>>>>>>>>> >>>>>>>>> >>>>>>>>> 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? >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> On 15.06.2016 17:53, Антон Жилин wrote: >>>>>>>>>> >>>>>>>>>>> Nice points, I also think that unless operators are from the >>>>>>>>>>> same domain, >>>>>>>>>>> more parentheses is better. >>>>>>>>>>> Other than that, what rules do we need? I can name these: >>>>>>>>>>> 1. Assignment operators have lower precedence than most operators >>>>>>>>>>> 2. Arithmetics has higher precedence than comparative and logical >>>>>>>>>>> operators. I don't think that ?? belongs to arithmetics, it's >>>>>>>>>>> more like >>>>>>>>>>> control flow. >>>>>>>>>>> 3. Unary operators obviously have higher precedence than >>>>>>>>>>> everything >>>>>>>>>>> >>>>>>>>>>> I didn't read se-0077 in details, so have no opinion. Probably >>>>>>>>>>>> you can >>>>>>>>>>>> >>>>>>>>>>> describe main ideas of it here in two words. >>>>>>>>>>> Replace numeric precedence with precedence relationships between >>>>>>>>>>> pairs of >>>>>>>>>>> operators. If precedence between two operators is undefined, we >>>>>>>>>>> cannot omit >>>>>>>>>>> parentheses. >>>>>>>>>>> >>>>>>>>>>> My thought was basically: "parentheses between some operators >>>>>>>>>>> must be >>>>>>>>>>> enforced by the language" <=> "SE-0077 is needed" >>>>>>>>>>> >>>>>>>>>>> - Anton >>>>>>>>>>> >>>>>>>>>>> 2016-06-15 17:17 GMT+03:00 Vladimir.S <[email protected] >>>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 15.06.2016 16:43, Антон Жилин via swift-evolution wrote: >>>>>>>>>>> >>>>>>>>>>> `b + c * d / e` is not, obviously. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> obviously, for math operators it seems like we don't need any >>>>>>>>>>> clarifications >>>>>>>>>>> >>>>>>>>>>> `a ? b : c + x + y` -- I'd also say not, because, well, >>>>>>>>>>> it's ternary >>>>>>>>>>> operator, the special case that everyone should know >>>>>>>>>>> (otherwise it >>>>>>>>>>> looks >>>>>>>>>>> like a mess with ? and : operators). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yes, it's ternary operator. But is it >>>>>>>>>>> a ? b : (c + x + y) >>>>>>>>>>> or >>>>>>>>>>> (a ? b : c) + x + y >>>>>>>>>>> >>>>>>>>>>> IMO ambiguous. >>>>>>>>>>> >>>>>>>>>>> `a ?? x + y + z` -- maybe. If not for analogies with || >>>>>>>>>>> and && and >>>>>>>>>>> knowing >>>>>>>>>>> about @autoclosure, I'd say that priority of ?? should >>>>>>>>>>> be very high. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The same, is it >>>>>>>>>>> a ?? (x + y + z) >>>>>>>>>>> or >>>>>>>>>>> (a ?? x) + y + z >>>>>>>>>>> >>>>>>>>>>> ? 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. >>>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> Now that I think about it, if job of SE-0077 could be >>>>>>>>>>> done with a >>>>>>>>>>> linter, >>>>>>>>>>> then... do we still need it? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I didn't read se-0077 in details, so have no opinion. >>>>>>>>>>> Probably you can >>>>>>>>>>> describe main ideas of it here in two words. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Anton >>>>>>>>>>> >>>>>>>>>>> 2016-06-15 16:00 GMT+03:00 Vladimir.S <[email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>>>: >>>>>>>>>>> >>>>>>>>>>> As I understand, the question is if >>>>>>>>>>> >>>>>>>>>>> `a ?? x + y + z` >>>>>>>>>>> and >>>>>>>>>>> `a ? b : c + x + y` >>>>>>>>>>> (or `b + c * d / e`) >>>>>>>>>>> >>>>>>>>>>> an "ambiguous case" ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 15.06.2016 15:42, Антон Жилин via swift-evolution >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> It's tempting to mention SE-0077 in this >>>>>>>>>>> context. If it's >>>>>>>>>>> accepted, >>>>>>>>>>> we will >>>>>>>>>>> be able to make omission of parentheses an error >>>>>>>>>>> in >>>>>>>>>>> ambiguous cases. >>>>>>>>>>> >>>>>>>>>>> - Anton >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> swift-evolution mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> <mailto:[email protected] <mailto: >>>>>>>>>>> [email protected]>> >>>>>>>>>>> >>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> swift-evolution mailing list >>>>>>>>>>> [email protected] <mailto: >>>>>>>>>>> [email protected]> >>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>> swift-evolution mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>> -- >>>>> -Saagar Jha >>>>> >>>> >>>> -- >>> -Saagar Jha >>> >> -- > -Saagar Jha >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
