strawman proposal for base4 and base 32 integer literals

# Shaun Moss (6 years ago)

I'm new to the list so please forgive me if I breach etiquette.

I have drafted a proposal for addition to the ES spec: mossy2100/ecmascript/blob/master/base4and32literals.md

If anyone has a few spare minutes, I'd be grateful if you could please give it a quick look over. I'd really appreciate any feedback on how to improve or advance it. I haven't looked into implementation details yet but I will soon.

Thank you Shaun

# Peter Jaszkowiak (6 years ago)

You don't have nearly enough discussion of use cases. Without that, especially since parseInt(str, radix) already exists, this is unlikely to go anywhere. Also, your base32 system is inconsistent with how parseInt(str, 32) currently behaves, which further decreases the likelihood of it being accepted.

Base 4 has few use cases because it only saves 1 character per bit-couple.

# Shaun Moss (6 years ago)

The second point is very helpful, thank you, Peter. I didn't realise that parseInt() already parsed letters A-V as values 10-31. Obviously any syntax for literals would need to be compatible with this (it's the same as the base32hex proposal in RFC 2938).

Thank you Shaun

# Carsten Bormann (6 years ago)

On Oct 8, 2018, at 06:14, Shaun Moss <shaun at astron.software> wrote:

base32hex proposal in RFC 2938

There are lots of “base 32” encodings. The most definitive document here is RFC 4648, which provides “base32” (alphabet “ABCDEFGHIJKLMNOPQRSTUVWXYZ234567”, which is closer to base64) in addition to the above (“0123456789ABCDEFGHIJKLMNOPQRSTUV”) which is called “base32hex” there as well. There is also a (different) “base32” in RFC 6189, with the alphabet “ybndrfg8ejkmcpqxot1uwisza345h769”, and tons of ones defined in specific applications. Any useful base32 function probably should take the alphabet as an argument. A base32 decoder may (or may not) want to be case-insensitive.

Grüße, Carsten

# kdex (6 years ago)

Sorry, but I highly doubt that it's worth reserving syntax for two bases for which even the author suggests their lesser usefulness.

This is best kept in user-space. Base-4 numbers should already be covered by this[1] proposal.

As for base 32, Carsten has already pointed out the problem of non-unique encodings (and this is true for every radix greater than 10).

If (your specific encoding of) base-32 literals were to be implemented in user-space, I think we could get away with extensible string literals, i.e. something akin to:

const base32 = string => { /* …  */ };

console.log("10"_base32); // logs 32

[1] tc39/proposal

# Bob Myers (6 years ago)

Why not used a tagged template literal, as in

base32`123EFG`

Bob