[swift-evolution] Nil coalescing operator precedence
Xiaodi Wu
xiaodi.wu at gmail.com
Wed Jun 15 13:55:59 CDT 2016
I was asking about only bitwise operators, but the reply was more general.
One reply from Chris Lattner:
> On Feb 13, 2016, at 6:32 AM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Not sure if this is intentional, a bug, and/or a topic for evolution:
> >
> > In Swift, bitwise operators seem to have a different precedence in
> > relation to other operators than they do in (all other?) C-family
> > languages, at least per documentation.
> Yep, this is true, and this is intentional. Swift has a greatly
> simplified and rationalized set of precedences, and yes, that means they
> differ from C.
On Wed, Jun 15, 2016 at 1:46 PM, Saagar Jha <saagarjha28 at gmail.com> wrote:
>
> 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/bd84eacf/attachment.html>
More information about the swift-evolution
mailing list