Error with shiftoperator <<

[DartBot]

This issue was originally filed by @pjako

---

What steps will reproduce the problem?
void main() {
  print(1 << (-21));
}

What is the expected output? What do you see instead?
2048

got:
Unhandled exception:
Illegal argument(s): -21
 0. Function: 'Smi.shlFromInt' url: 'bootstrap_impl' line:1590 col:1
 1. Function: 'IntegerImplementation.<<' url: 'bootstrap_impl' line:1481 col:28
 2. Function: '::main' url: 'file:///C:/Users/pjako/dart/shifttest/shifttest.dart' line:3 col:11

What version of the product are you using? On what operating system?
6943
Windows

Please provide any additional information below.

[DartBot]

This comment was originally written by @pjako

---

Also not working with build 7232, bug appears in dartium and the standalone VM, but it works fine if I compile it to js.

[ghost]

It is presumed that a negative left shift should give an error, as its behavior is undefined. Assigning to Area-Language for clarification.

Note that ISO C states:
1185 If the value of the right operand is negative or ... , the behavior is undefined.

---

cc @floitschG.
Added Area-Language, Triaged labels.

[DartBot]

This comment was originally written by @pjako

---

yes, but it seems that it works not this way in javascript (as well as in c#), both operate fine with such an operation.

[DartBot]

This comment was originally written by @pjako

---

You can also try it on trydart...
http://try.dartlang.org/s/d1k-

and it works just fine

[floitschG]

There are two (related) issues reported in this bug-report:

1. should it be allowed to do negative shifts, and if yes,
2. what should happen to bits that are shifted out. JavaScript, for example, does a cyclic shift when the shift amount is negative.

Cyclic shifts don't make sense when integers are of infinite precision. So, if Dart allowed negative shifts, it would be equivalent to shifting to the other direction with the negated amount. Example: 1 << -3 would be equivalent to 1 >> 3.

This means that the expected result of this feature request, (1 << -21 => 2048) is out.
I'm tending towards closing this feature request as "working as intended", but, for now, I will leave it open to discuss question 1.
Personally I think that non-negative shifts can catch errors, and that it is easy to work around it, if the users expects negative inputs:
 int shiftLeft(int x, int i) => i >= 0 ? x << i : x >> -i;

Wrt the dart-to-JS compiler, and dartboard (try.dartlang.org): the number semantics of programs that are compiled to JavaScript do not always follow the spec.
We are working on improving this (and the latest iteration of the compiler already checks for negative inputs), but in the near future numbers will unfortunately behave differently in JavaScript than they do in Dart.

[anders-sandholm]

Added this to the M1 milestone.

[gbracha]

Since the shift operators are user-defined, I see this as a library issue. Furthermore, it is not a defect, but a request for a change in behavior. As to the substance, I agree with Florian.

---

Removed Type-Defect, Area-Language labels.
Added Type-Enhancement, Area-Library labels.

[lrhn]

Florian is correct: Negative shifts makes no sense when you have arbitrary precision integers.
In ECMAScript, you have only 32-bit integers wrt. bit operations, and the shift is normalized to a number in the range 0..31 (by using the value (shift & 0x1f)).
In Dart, we can't normalize it to anything reasonable - the corresponding operation would be doing modulo with Infinity.

And we don't want a left shift by a negative amount to be a right shift. That's an error waiting to be ignored.

All in all, I see no solution to giving a meaning to "1 << -21". We'll keep throwing an argument error for negative shifts.

---

Added WontFix label.