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
