[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