[swift-evolution] Nil coalescing operator precedence

[Vladimir.S]

 >  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?)  ?

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 <svabox at gmail.com
> <mailto:svabox at 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 <svabox at gmail.com
>         <mailto:svabox at gmail.com>
>         <mailto:svabox at gmail.com <mailto:svabox at 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 at swift.org
>         <mailto:swift-evolution at swift.org>
>         <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>                 https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
>         _______________________________________________
>         swift-evolution mailing list
>         swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>         https://lists.swift.org/mailman/listinfo/swift-evolution
>
>