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.
On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин <antonyzhi...@gmail.com> 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 <saagarjh...@gmail.com>: > >> 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 < >> swift-evolution@swift.org> 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 Антон Жилин <antonyzhi...@gmail.com> >>> 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 Антон Жилин <antonyzhi...@gmail.com>: >>>> >>>>> 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 <xiaodi...@gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution < >>>>>> swift-evolution@swift.org> 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 <sva...@gmail.com >>>>>>>> <mailto:sva...@gmail.com>>: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 <sva...@gmail.com >>>>>>>> <mailto:sva...@gmail.com> >>>>>>>> <mailto:sva...@gmail.com <mailto:sva...@gmail.com>>>: >>>>>>>> >>>>>>>> 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 >>>>>>>> swift-evolution@swift.org >>>>>>>> <mailto:swift-evolution@swift.org> >>>>>>>> <mailto:swift-evolution@swift.org <mailto: >>>>>>>> swift-evolution@swift.org>> >>>>>>>> >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> swift-evolution mailing list >>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org >>>>>>>> > >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> swift-evolution@swift.org >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> -- >> -Saagar Jha >> > > -- -Saagar Jha
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution