Re: [swift-evolution] [Discussion] Breaking precedence

> On Aug 2, 2016, at 2:41 PM, Anton Zhilin via swift-evolution > wrote: > > Here is the proposal draft: > https://github.com/Anton3/swift-evolution/blob/remove-precedence-bitwise-arithmetic.md/proposals/-remove-precedence-bitwise-arithmetic.md > >

Re: [swift-evolution] [Discussion] Breaking precedence

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

Re: [swift-evolution] [Discussion] Breaking precedence

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 于2016年8月3日 周三05:55写道： > Well, there I disagree. All of these operations take integers and

Re: [swift-evolution] [Discussion] Breaking precedence

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",

Re: [swift-evolution] [Discussion] Breaking precedence

2016-08-03 0:46 GMT+03:00 Xiaodi Wu : > 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

Re: [swift-evolution] [Discussion] Breaking precedence

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

Re: [swift-evolution] [Discussion] Breaking precedence

Here is the proposal draft: https://github.com/Anton3/swift-evolution/blob/remove-precedence-bitwise-arithmetic.md/proposals/-remove-precedence-bitwise-arithmetic.md Motivation will be the most difficult section here. 2016-08-02 23:30 GMT+03:00 Xiaodi Wu : > Let me give

Re: [swift-evolution] [Discussion] Breaking precedence

Let me give you theoretical basis for why I'm +0.5 on branching off binary operators but not these other ones. Félix is absolutely right that `a << b / c` mixes two things. It's not merely that they're in two "different" domains. It's that these two operators take the same values of the same type

Re: [swift-evolution] [Discussion] Breaking precedence

2016-08-02 23:06 GMT+03:00 Xiaodi Wu : > I'm not sure how you're coming up with "domain areas". Ranges have numbers > as bounds; those are typically computed by arithmetic. > > Virtually the entire stdlib exists to support language features; all other > facilities found in

Re: [swift-evolution] [Discussion] Breaking precedence

I'm not sure how you're coming up with "domain areas". Ranges have numbers as bounds; those are typically computed by arithmetic. Virtually the entire stdlib exists to support language features; all other facilities found in other languages' "standard library" are in Foundation. As I mentioned,

Re: [swift-evolution] [Discussion] Breaking precedence

If operator <+> is used in one domain area, and operator <-> is used in another domain area, then we should not make everyone keep in mind both domain areas simultaneously. Another explanation: operator ... does not belong to "core", "control" operators, it belongs to Ranges part of standard

Re: [swift-evolution] [Discussion] Breaking precedence

What's the benefit? Is there anyone confused by a...b+c? On Tue, Aug 2, 2016 at 14:13 Anton Zhilin wrote: > 2016-08-02 21:56 GMT+03:00 Xiaodi Wu : > >> I can sort of see what this is getting at, but I simply have no way of >> evaluating whether it's

Re: [swift-evolution] [Discussion] Breaking precedence

2016-08-02 21:56 GMT+03:00 Xiaodi Wu : > I can sort of see what this is getting at, but I simply have no way of > evaluating whether it's sensible or not without actual examples in code. > This is, again, a more expansive change than discussed. I'd be interested > in seeing

Re: [swift-evolution] [Discussion] Breaking precedence

I can sort of see what this is getting at, but I simply have no way of evaluating whether it's sensible or not without actual examples in code. This is, again, a more expansive change than discussed. I'd be interested in seeing your write-up on separating arithmetic and bitwise/bitshift operators

Re: [swift-evolution] [Discussion] Breaking precedence

> On Aug 2, 2016, at 11:09 AM, Nevin Brackett-Rozinsky > wrote: > > @Xiaodi > Actually, I think just about all the rest of the precedence rules “make > sense” intuitively: > > `a | b == c % d` > `a < b ? c : d * e` > `a ?? b - c` > `a...b+c` > > These all

Re: [swift-evolution] [Discussion] Breaking precedence

On Tue, Aug 2, 2016 at 1:07 PM, Anton Zhilin wrote: > 2016-08-02 19:08 GMT+03:00 Xiaodi Wu : > >> That's an excellent point, actually. Would there be downsides not yet >> considered? >> >> On Tue, Aug 2, 2016 at 11:03 Félix Cloutier

Re: [swift-evolution] [Discussion] Breaking precedence

2016-08-02 21:09 GMT+03:00 Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com>: > @Xiaodi > Actually, I think just about all the rest of the precedence rules “make > sense” intuitively: > > `a | b == c % d` > `a < b ? c : d * e` > `a ?? b - c` > `a...b+c` > > These all do what they ought

Re: [swift-evolution] [Discussion] Breaking precedence

On Tue, Aug 2, 2016 at 1:09 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > @Xiaodi > Actually, I think just about all the rest of the precedence rules “make > sense” intuitively: > Disagree vehemently. See below: > `a | b == c % d` > `a < b ? c : d * e` > I, like

Re: [swift-evolution] [Discussion] Breaking precedence

2016-08-02 19:08 GMT+03:00 Xiaodi Wu : > That's an excellent point, actually. Would there be downsides not yet > considered? > > On Tue, Aug 2, 2016 at 11:03 Félix Cloutier wrote: > >> These expressions mix two types of logic that have different >>

Re: [swift-evolution] [Discussion] Breaking precedence

@Xiaodi Actually, I think just about all the rest of the precedence rules “make sense” intuitively: `a | b == c % d` `a < b ? c : d * e` `a ?? b - c` `a...b+c` These all do what they ought to, and of course assignment naturally has low precedence. Really the only confusing ones are operators

Re: [swift-evolution] [Discussion] Breaking precedence

This is an expansive argument you advance. Should users be expected to learn *any* rules of precedence beyond those of basic arithmetic? It would seem that you are arguing no. Yet Swift just went through an arduous redesign to permit--nay, improve--exactly that. On Tue, Aug 2, 2016 at 12:30 Nevin

Re: [swift-evolution] [Discussion] Breaking precedence

> On Aug 2, 2016, at 10:30 AM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Speaking for myself, I will *never* remember which of `&&` and `||` has > higher precedence. I had the opposite experience. The point here is don’t rob others for our own

Re: [swift-evolution] [Discussion] Breaking precedence

Speaking for myself, I will *never* remember which of `&&` and `||` has higher precedence. I think of them as peers, so I always use parentheses around them, and whenever I read code that mingles them without parentheses its meaning is *unclear* to me. One of Swift’s main goals is clarity at the

Re: [swift-evolution] [Discussion] Breaking precedence

That's an excellent point, actually. Would there be downsides not yet considered? On Tue, Aug 2, 2016 at 11:03 Félix Cloutier wrote: > These expressions mix two types of logic that have different implications. > For instance, `a * 16` and `a << 4` are "mostly equivalent",

Re: [swift-evolution] [Discussion] Breaking precedence

These expressions mix two types of logic that have different implications. For instance, `a * 16` and `a << 4` are "mostly equivalent", except that `a * 16` will crash on overflow. In these cases, I find that grouping provides some visual insulation that groups off the somewhat subtle

Re: [swift-evolution] [Discussion] Breaking precedence

On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier wrote: > I don't think that "intuitive" or "non-intuitive" is what you'd be looking > for. There is nothing intuitive about multiplications having a higher > precedence than additions; it's just a matter of conventions. I'm not a

Re: [swift-evolution] [Discussion] Breaking precedence

I don't think that "intuitive" or "non-intuitive" is what you'd be looking for. There is nothing intuitive about multiplications having a higher precedence than additions; it's just a matter of conventions. I'm not a maths expert (as Stephen showed, I didn't even give the right explanation to

Re: [swift-evolution] [Discussion] Breaking precedence

> On Aug 2, 2016, at 12:18 AM, Félix Cloutier via swift-evolution > wrote: > > I disagree. The binary operators have properties that are comparable to > arithmetic operators, and their precedence is easy to define as such. & has > multiplication-like properties

Re: [swift-evolution] [Discussion] Breaking precedence

Assignment has the lowest precedence. 'x = condition ? y : z' doesn't make sense if assignment is resolved before the ternary; the compiler would complain that perhaps you meant '==' instead of '='. There was an idea ages ago for essentially a 'switch expression' which was effectively ternary for

Re: [swift-evolution] [Discussion] Breaking precedence

2016-08-02 7:18 GMT+03:00 Félix Cloutier : > I disagree. The binary operators have properties that are comparable to > arithmetic operators, and their precedence is easy to define as such. & has > multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has >

Re: [swift-evolution] [Discussion] Breaking precedence

Right. I asked about this issue some months ago on this list, and Chris was very patient to confirm that what you described was indeed the thinking behind the rationalized precedence of bitwise operators in Swift. On Mon, Aug 1, 2016 at 23:18 Félix Cloutier wrote: >

Re: [swift-evolution] [Discussion] Breaking precedence

I disagree. The binary operators have properties that are comparable to arithmetic operators, and their precedence is easy to define as such. & has multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has subtraction-like

Re: [swift-evolution] [Discussion] Breaking precedence

> On Aug 1, 2016, at 3:01 PM, Anton Zhilin via swift-evolution > wrote: > 2016-08-02 0:52 GMT+03:00 Xiaodi Wu >: > On Mon, Aug 1, 2016 at 4:41 PM, Anton Zhilin via swift-evolution >

Re: [swift-evolution] [Discussion] Breaking precedence

2016-08-02 0:52 GMT+03:00 Xiaodi Wu : > On Mon, Aug 1, 2016 at 4:41 PM, Anton Zhilin via swift-evolution < > swift-evolution@swift.org> wrote: > >> Disclaimer: I have not (yet) prepared a proposal, or even something that >> could be considered a draft, but I want to hear

Re: [swift-evolution] [Discussion] Breaking precedence

On Mon, Aug 1, 2016 at 4:41 PM, Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: > Disclaimer: I have not (yet) prepared a proposal, or even something that > could be considered a draft, but I want to hear public opinion on the topic. > > SE-0077 (about precedence groups) has