[swift-evolution] Nil coalescing operator precedence
Saagar Jha
saagarjha28 at gmail.com
Wed Jun 15 13:46:49 CDT 2016
On Wed, Jun 15, 2016 at 11:36 AM Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> On Wed, Jun 15, 2016 at 1:31 PM, Saagar Jha <saagarjha28 at gmail.com> wrote:
>
>> Yes. They’re all operators we know about already, and the same argument
>> applies. Just like you wouldn’t change + to have a higher precedence than
>> *, bitwise operators already have their own, uniform precedences. I can’t
>> see any reason not to have one, other than confusion from those who aren’t
>> completely sure how they function-in which case they’re better of taking a
>> look at the docs (or Quick Help, as another thread suggests) to learn how
>> they work.
>>
>
> FYI, the relative precedence of arithmetic and bitwise operators is not
> the same across languages in the C family. Here, Swift diverges from C and
> resembles Go. I raised this point some time ago and was told in no
> uncertain terms by the core team that it was intentional and that they were
> satisfied with the result.
>
Is the core team talking only for bitwise operators or all of them?
>
>
>>
>> On Wed, Jun 15, 2016 at 11:23 AM Антон Жилин <antonyzhilin at gmail.com>
>> wrote:
>>
>>> 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
>>>>
>>>
>>> --
>> -Saagar Jha
>>
> --
-Saagar Jha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/9f103b6d/attachment.html>
More information about the swift-evolution
mailing list