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