[swift-evolution] Nil coalescing operator precedence

Xiaodi Wu xiaodi.wu at gmail.com
Wed Jun 15 13:36:10 CDT 2016


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

> Yes. They’re all operators we know about already, and the same argument
> applies. Just like you wouldn’t change + to have a higher precedence than
> *, bitwise operators already have their own, uniform precedences. I can’t
> see any reason not to have one, other than confusion from those who aren’t
> completely sure how they function-in which case they’re better of taking a
> look at the docs (or Quick Help, as another thread suggests) to learn how
> they work.
>

FYI, the relative precedence of arithmetic and bitwise operators is not the
same across languages in the C family. Here, Swift diverges from C and
resembles Go. I raised this point some time ago and was told in no
uncertain terms by the core team that it was intentional and that they were
satisfied with the result.


>
> On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин <antonyzhilin at gmail.com>
> wrote:
>
>> What do you think about arithmetic and bitwise operators? Arithmetic and
>> casting? Should they have defined precedence?
>>
>> - Anton
>>
>> 2016-06-15 21:17 GMT+03:00 Saagar Jha <saagarjha28 at gmail.com>:
>>
>>> 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. 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
>>>
>>
>> --
> -Saagar Jha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/93ab8b23/attachment.html>


More information about the swift-evolution mailing list