[swift-evolution] Nil coalescing operator precedence
Xiaodi Wu
xiaodi.wu at gmail.com
Wed Jun 15 13:00:18 CDT 2016
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
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/8d3b66ca/attachment.html>
More information about the swift-evolution
mailing list