[swift-evolution] Nil coalescing operator precedence
Saagar Jha
saagarjha28 at gmail.com
Wed Jun 15 13:31:51 CDT 2016
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.
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/3981985a/attachment.html>
More information about the swift-evolution
mailing list