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
