[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