Add binary integer literals

[DartBot]

This issue was originally filed by ladicek@gmail.com

---

When working with bits and bytes, having binary integer literals comes handy, as a lot of languages acknowledged (Python, Ruby, Java, even GCC has them as an extension). I believe that the reasoning behind adding binary literals to Java 7, as per http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000929.html, is equally valid to Dart, and therefore I propose to add binary literals in the same form ("0b100000" as an equivalent of "0x20"). I think that implementation is no concern (I did it in the VM and it was pretty straightforward, as I describe in http://ladicek.github.com/2012/04/29/hacking-the-vm-adding-binary-integer-literals.html).

[anders-sandholm]

Removed Type-Defect label. Added Type-Enhancement, Area-Language, Triaged labels.

[gbracha]

Set owner to @gbracha. Added Accepted label.

[gbracha]

Probably should be treated in the context of a general radix indicator.

---

Added this to the Later milestone.

[kasperl]

Removed this from the Later milestone. Added Oldschool-Milestone-Later label.

[kasperl]

Removed Oldschool-Milestone-Later label.

[srawlins]

+1

C++14 is scheduled to have binary literals as well.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf http://www.informit.com/articles/article.aspx?p=2209021

[d-silveira]

any news on this 8 years on?

[munificent]

No news, sorry. We've been focused on higher-value features like extension methods and non-nullable types. I do hope that we get to smaller quality of life features like this at some point, but we've got some more foundational stuff to do first.

[mkorbel1]

This would be super useful when dealing with hardware modelling in Dart, for example with ROHD

[lrhn]

If we introduce binary literals, I'd very much like to also get digit separators (#2). A literal like 0b111111111111111 is incredibly hard to read compared to 0b111_1111_1111_1111 (yep, there were 15 digits).

It's the same for other large number literals with repeated digits, but for binary ones, the length grows much faster and there is more repetition since there's only two digits to choose from.

[Zekfad]

This feature with #2 would be very helpful when working with binary data blobs (binary files and network protocols) I see small-feature badge, is there any plans for this in this year?

[munificent]

No plans currently. We've been focused on much higher priority language features.

[srawlins]

I have a mostly complete prototype here: https://dart-review.googlesource.com/c/sdk/+/378104

Would the language team accept this if I sent it out for review, with binary integer literals supported behind a language experiment?

[lrhn]

Personally I'd like it. We may want a little design round, just to be safe, since this issue predates ... well, integers as they currently exist.

One thing I can see that is relevant, "now" that integers are fixed size, is whether we allow a 64-bit unsiged binary literal, like we do for hex literals. (I'd say "yes", 0b1....64 1-digits total.....1 would have the value -1 on native, just like 0xFFFF_FFFF_FFFF_FFFF does.)

Another is the parsing experience. I'd let scanning include invalid decimal digits, and then report it as an error, rather than stop at the first one. That way 0b11112111 would say "2 is not a binary digit" rather than "unexpected number 2111".

Could/should we allow the mantissa of a double to be binary? 0b111.101e10? We can't do that with hex beacause e is a digit. I've seen other languages use p instead, for "power", which is then a power of 2 instead of 10. That's another option. (Answers: "Yes" and "probably not". You can do 0b111101 / 0b1000 * 1e10, and you're lucky!)

[rakudrama]

Although I have wanted binary literals forever, I think I prefer the general radix version, e.g., 2r1001 instead of 0b1001. The general form has the advantage of covering other missing features like octal literals.

For binary literals, the general r form takes up the same number of characters, but to my eye the prefix looks more distinct from the digits. b looks a bit like the digits 0 and 1 , with rounded and tall elements. r has a distinct shape. (0o for octal is even worse in this regard).

[lrhn]

(If you think the prefix and the numbers run together, you can always do 2r0_1110_1110. It does feel a little messy. Maybe use 2#11101101? It's not like we allow symbols to start with digits, or follow integer literals otherwise.)

[leafpetersen]

We talked about this today. There is a general consensus that a way to express binary literals would be very useful. There is some sense (not universally held) that octal would also be worth supporting. There is a general consensus that an arbitrary radix form doesn't pull its weight. General radix numbers add a great deal of complexity and testing requirements, and it seems likely that if we postpone binary literals in favor of arbitrary radix numbers we would simply never ship either. Given that almost all of the possibly radix choices are unlikely to ever be used in practice, this seems like a bad tradeoff. Given this, we propose to: 1) Accept the binary literal implementation 2) Keep octal literals as an option for future addition 3) Leave arbitrary radix literals as "not planned" (we can always change our mind on this later at the expense of having two ways to write binary and decimal literals)

cc @srawlins @dart-lang/language-team