[swift-evolution] Nil coalescing operator precedence

Vladimir.S svabox at gmail.com
Wed Jun 15 12:34:46 CDT 2016


On 15.06.2016 19:15, Xiaodi Wu wrote:
>
>
> On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at 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?

Hmm... The initial question of this thread was about
let result = v1 ?? 0 + v2 ?? 0
Which will resolve to
let result = v1 ?? (0 + v2 ?? 0)

And then the question was raised regarding the ternary operator:
a ? b : c + x + y

So, the question was can we require a parentheses in these cases and if we 
can, how. I'm not sure if these questions about precedence or associativity.

>
>
>
>     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>
>         <mailto: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>>
>                 <mailto: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>>
>                 <mailto: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>
>         <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
>
>


More information about the swift-evolution mailing list