[swift-evolution] Nil coalescing operator precedence

Xiaodi Wu xiaodi.wu at gmail.com
Wed Jun 15 13:35:00 CDT 2016


On Wed, Jun 15, 2016 at 1:17 PM, Saagar Jha <saagarjha28 at gmail.com> wrote:

> 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.
>

Well, as I touched on above, I argue that the ternary operator is
constrained to be low precedence because of the syntax itself. Here's why:

* Since it's a single operator, it has only one precedence--that is, to the
extent that it makes sense to think about them separately, ? and : have
equal precedence.
* Imagine the statement `a ? c + x + y : b`. If this statement is to be
syntactically correct, + *must* have higher precedence than ?: because
there is no such thing as `(a ? c) + x + (y : b)`.
* Therefore, by symmetry, `a ? b : c + x + y` must mean `a ? b : (c + x +
y)`.


> 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 at 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 Антон Жилин <antonyzhilin at 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 Антон Жилин <antonyzhilin at 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.wu at gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 15, 2016 at 11:07 AM, Vladimir.S via swift-evolution <
>>>>> 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?
>>>>>
>>>>>
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> --
> -Saagar Jha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/25a13009/attachment.html>


More information about the swift-evolution mailing list