[swift-evolution] Nil coalescing operator precedence

[Xiaodi Wu]

On Wed, Jun 15, 2016 at 5:35 AM, Jo Albright <me at jo2.co> wrote:

> I agree, precedence should be left for math operations that are known by
> all.
>

Practically, this is largely the case, in that stdlib operators are more or
less restricted to math operations. Previously, I raised the issue of
bitwise operators and was told that their precedence had been intentionally
rationalized to parallel the more familiar math operations; moreover, Swift
already forces parentheses when bitwise operators are used in combinations
with some other operators that are ambiguous. Other than those, the
operators that are not really related to arithmetic are the range (... and
..<), nil coalescing (??), and ternary (?:) operators. (And assignment
operators, but those are special.)


> Since this is not a normal operation, it should be left up to the
> developer to tell the computer what to do. The computer should not assume
> for you how to handle complex operations next to a nil coalescing operator.
>

In this case, regarding non-arithmetic operators, all of these are actually
lower precedence than the arithmetic ones. That's a teachable rule, and
also largely holds true for other languages in the C family as well.


> I am intrigued with the idea of explaining to the developer what the order
> of their current code will run. Almost like a hint or warning. If there was
> a feature in Xcode that explained the order of operations for a given line
> of code, this would help the developer choose where to put parenthesis.
> But, I don’t believe we should suggest where the parenthesis go (this
> becomes another assumption on how they want their code to be). Misaligned
> assumptions can frustrate the developer and slow down their coding or
> confuse them more.
>
> What does everyone think about adding a visual explanation with the order
> of operations in a formula.
>
> Example:
>
> var a = b + c * d / e
>
> Visual Hint (maybe popup like Quick Help or something simpler)
>
> var a = (b + ((c * d) / e))
>
> Or
>
> var x = c * d
> var y = x / e
> var z = b + y
>
> Some way to quickly represent the order to inform a developer of the
> current order.
>
> *I believe there needs to be more communication between the developer and
> the computer. An open dialog about what the developer is trying to tell the
> computer to do. If the computer says “this is what I think you are telling
> me to do”, the developer then can decide if they wrote the correct line of
> code.*
>
> Thanks,
> Jo
>
> On Jun 15, 2016, at 4:31 AM, Haravikk via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On 15 Jun 2016, at 00:21, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
> I don't know that it's feasible to warn on every use of operators with
> mixed precedence. Doing so would effectively do away with the concept of
> precedence at all, since everything would have to be grouped by parentheses
> in order to avoid warnings. (The core team has been pretty clear that there
> will be no 'optional' warnings, and in certain organizations warnings are
> regarded as errors.)
>
>
> Personally I’m against precedence entirely, as I’m terrible at remembering
> the order and even if I could I’d still see myself making tons of mistakes,
> as a result I use parenthesis in all but the simplest statements just to be
> absolutely clear. The problem with precedence is that while it lets the
> compiler choose a logical order to process expressions, you can never be
> sure that it’s actually the order the user intended.
>
> Still, I may be in the minority, not sure, maybe other people are happier
> with math operator precedence than I am. However, I think that effectively
> forcing parenthesis on ?? and ?: may be okay; most of the time these are
> used in simple, non-ambiguous cases (either on their own, or with an
> assignment), so parenthesis shouldn’t be needed, but anywhere they’re
> within larger statements I think it makes sense to encourage parenthesis
> use so the compiler can be certain it isn’t guessing at your meaning. I
> mean it’s kind of like forcing a defensive coding style, but that’s not
> necessarily a bad thing; I’ve learned from experience that I suck at
> operator precedence and instead of wasting time looking it up to be sure,
> hurling a bunch of parenthesis in place not only clarifies my intent, but
> avoids the problem entirely, I wish more people would do it, as I still run
> into cases in other people’s code where it takes some time to figure out
> meaning (usually because these operator precedence obsessed monsters don’t
> leave comments either ;)
>
> Increasing the precedence won’t help IMO, as it remains just as possible
> for a user to make a mistake, plus we run the risk of changing the result
> of currently correct code that works fine with the current precedence but
> will suddenly give different results if evaluated sooner.
>
> So yeah, I think recommending parenthesis is a good compromise, and good
> style to encourage when using these operators in more complex cases, not
> just for avoiding mistakes but also to make the code more readable for
> others.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/011b7c58/attachment.html>