[swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu]

I think we can all agree that you should be allowed to use parentheses
whenever it helps you to clarify your meaning. I can also assure you,
however, that when you really get into using these operators for heavy
math, nesting (((()))) also hinders clarity.

As always, the question of how much of this choice should be enforced by
the compiler and standard library is a nuanced discussion. C, at one
extreme, has flourished with a much more complicated set of precedence
rules and no enforcement of how parentheses are used. Swift can and already
does do better; now, the question is, are even more restrictions better?
How much more and how much better?

My personal opinion is that we have nearly the right amount of rules, with
maybe one or two more tweaks at most. Reason: any additional requirements
by the compiler and standard library cannot be optionally waived by the
user, but a user can always choose to add more parentheses than required.
Designers of Swift can help readers of code by _encouraging_ writers of
code to improve clarity, but in the end we must design the language for a
reasonably well-meaning writer; it's a fool's errand to try to use the
standard library to defend clarity against the wishes of an unwilling
writer.
On Tue, Aug 2, 2016 at 19:10 Boris Wang <kona.ming at gmail.com> wrote:

> C is my working language，I don' want to remember too much rules for
> operator, just use parentheses.
>
> It's more reliable than the complicated rules.
>
>
> Xiaodi Wu via swift-evolution <swift-evolution at swift.org>于2016年8月3日
> 周三05:55写道：
>
>> Well, there I disagree. All of these operations take integers and produce
>> other integers. As we've discussed, the bitwise operators resemble
>> multiplication or addition in particular ways; not so different at all.
>> This is IMO a weak argument because you're arguing gradations of "so
>> different", which is entirely subjective in the end.
>>
>> What I'm saying is that I would be mildly in favor of your proposal
>> because I can justify it on the basis of something black-and-white:
>> conflicting "levels" at which these operators work on integers (collection
>> of bits vs. element in the set of all integers) and the concomitant
>> differences regarding when these operators trap.
>> On Tue, Aug 2, 2016 at 16:49 Anton Zhilin <antonyzhilin at gmail.com> wrote:
>>
>>> 2016-08-03 0:46 GMT+03:00 Xiaodi Wu <xiaodi.wu at gmail.com>:
>>>
>>>> It's not that << will overflow and / will not. Substitute * for / and
>>>> the argument would be the same. The difference is that << traps when you
>>>> shift more than the total number of bits but does *not* trap when you shift
>>>> numbers off as would arithmetic exponentiation; * traps on overflow. Thus,
>>>> what << is concerned about is the bits (as it should), but * is concerned
>>>> about the max representable value.
>>>
>>>
>>> Substitute * for / and my argument would also be the same :)
>>>
>> _______________________________________________
>
>
>> 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/20160803/8a1d14db/attachment.html>