[swift-evolution] Nil coalescing operator precedence
Антон Жилин
antonyzhilin at gmail.com
Wed Jun 15 13:23:48 CDT 2016
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/856fbb59/attachment.html>
More information about the swift-evolution
mailing list