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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution