[swift-evolution] Nil coalescing operator precedence

Антон Жилин antonyzhilin at gmail.com
Wed Jun 15 12:54:51 CDT 2016


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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/e45b021b/attachment.html>


More information about the swift-evolution mailing list