Add arbitrary-base literals

[brson]

We now have hex, binary, and octal literals, but when will it end? #10243 suggested adding literals with any radix, like 64rABC. What say you?

[mletterle]

I like it. 👍

[huonw]

I like it, but I have some questions:

• Is case-insensitivity desirable? (i.e. maximum base == 36.)
• If it's not, could we add 2 extra characters to get up to base 64? (since 0-9, a-z, A-Z is 62 possible digits.)
• Would we keep 0b, 0o and 0x?
• How would this interact with syntax highlighters/editor modes? (It's well behaved in a grammar sense (i.e. it's regular), since one can hard code (2r[01]*)|(3r[012]*)|..., but doing that for all 36/whatever possible bases might be annoying?)

[mletterle]

Couldn't it be case-insensitive for radix below 36 and case-sensitive above?

I say the format just be ([0-9]+)[rR]([^\s]+)?

The common base64 indexing should be kept, and we could define an indexing up to base 95 using standard ASCII, alternatively the indexing for > 36 could simply be the order they appear after space.

Yes, the common bases should be kept.

[SiegeLord]

The current base variants have clear use-cases. I haven't seen a clear use case for arbitrary base numeric literals, and to that end I'd suggest using a syntax extension to do this. Depending on its design, it can avoid the character set issues and other tokenizing ambiguities. Possible API:

// Actual number in a string, to avoid tokenizing issues
base!(12, "1ab")
base!(1, "111111")
// Option to separate individual digits with a comma
// (similar to how sexagesimal digits were written by the Babylonians)
// thus avoiding an arbitrary maximum base. Individual digits written in
// the natively supported bases (2, 8, 10, 16)
base!(64, "10,32,17")
// Possible idea of where to stick the type ascription
base!(64, "32", u32)
// Also could work with floating point literals
// (although those actually have a clear use case
// and probably should be added in a non-syntax extension manner)
base!(16, "0x1.fffffffffffffp+1023", f32)

The floating point literal syntax was taken from #1433.

[mletterle]

I'm alright with the syntax extension approach as well, personally.

[sfackler]

Is there any use case for other bases? I don't think I've ever used or wanted to use any base other than 2, 8, 10 or 16 when programming.

Would this proposal support balanced ternary and base e?

[mattcarberry]

I like the syntax extention idea. One problem with the proposed arbitrary base literal syntax, is that there's no way to know whether the type suffix (u16,u32) is a type suffix or part of the number above a certain base without adding a token between them.

[alexcrichton]

Closing, a feature such as this needs to go through the RFC process we have in place now (didn't exist when this issue was created).