[swift-evolution] Nil coalescing operator precedence

Антон Жилин antonyzhilin at gmail.com
Wed Jun 15 11:52:33 CDT 2016


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/35f16c65/attachment.html>


More information about the swift-evolution mailing list