Pre-SIP: Support Binary Integer Literals


Support binary integer literals. For example, the binary literal 0b00101010 would have the integer value 42.


Several other major languages support binary integer literals, including Java (as of Java 7), Python and Rust.

Interactions with Other Language Features

Like other integer literals, binary integer literals support separators (_), which can greatly enhance the readability of larger values (e.g. 0b_1110_1101_1011_0111).


The implementation of binary integer literals is quite simple, and can be found at:


SIP document PR:

What would you think of supporting binary number literals via a string interpolator, alternatively?

val fortyTwo: Int = b"101010"
1 Like

Why a string interpolator for binary, but not for hex in that case. I think it should be the same for both of them


Does anyone in the @sip-committee want to champion this one?

I think this could be a good addition, but I believe we have space for it only after 3.0 is done.


Byte literals would also be neat. Somewhat orthogonal to this I suppose, but close enough to mention here. Do you have any appetite to bolt that on to this one Dale?

1 Like

It does not seem at all controversial to me, and I suspect that others feel the same. Perhaps it could be brought up extremely briefly, and if it does not have any dissent or further discussion wanted by anyone on the committee, it can be moved through. If someone does want to discuss something about it or doesn’t like it, the discussion can be tabled for after 3.0.

It just seems a bit silly to me to table such a trivial change for such a long time if there’s so little to discuss about it, and both the spec and compiler work are already complete.


I think they are not close enough to group. There is not (to my knowledge) any syntax that already has consensus (as 0b does) and fits neatly with the rest of the Scala syntax (e.g. a Rust-like i8 does not fit well with Int's lack of suffix and Long's L suffix). Additionally, there is no working implementation for it.

If you have a concrete proposal and an implementation, I do think it might be reasonable to tackle them together, but as it does not, I don’t think it adds anything to this proposal.

I was only joking when I suggested that if we support 0x_42 in Scala 2, people will lose interest in Scala 3. But it’s quite possible no one will have the resources to port their tables of binary constants to Scala 3 interpolator macros, that is, after they learn how to write interpolator macros.

However, since it takes about a year to merge a PR that corrects the caret in parse error messages, I think it’s reasonable for an actual feature to require in the 3-5 year range.

Some people boast how they’re moving the needle. I’m just trying to move the caret.

1 Like

Of course, 0b is the Byte value zero. But we should deprecate that straight off and recommend 0B because it’s too easy to accidentally add a digit 0b1 and wind up with an Int. That’s probably more of a hazard in emacs than vi.

Fair enough, I’ll draft a separate proposal for that.

I don’t mean to make it into a meme, but could this be implemented with a macro-backed string interpolator? That way it doesn’t add to the language/compiler, and the niche users that suffer this absence gain an improvement?

1 Like

Oh, woops, I’m echoing @julienrf

But why the dotty FromDigits feature is not enough?


Great idea. Perhaps it could make Scala more popular with the kids.


How about Byte(42)?

that’s a really neat feature I was unaware of! and perhaps it could work, although I’d probably want to get an Int back, not a custom type.

How does an opaque type of Int sound? You could even give it a Conversion[Binary, Int] instance, and you could even put that in the companion object so it’s always available for type adaptation…

It would be great to hear somebody from the scodec team like @mpilquist.