Inconsistent FFI naming for base encoders/decoders across Erlang and JavaScript

[xikaos]

Context

While working on #864 I noticed the Erlang and JavaScript FFI functions for base encoders/decoders using mixed naming styles (e.g. bit_array_base64_encode, base_decode64, encode64, base16_encode). This inconsistency increases mental overhead and makes future additions (e.g. base32) harder to align.

Current state (examples)

Erlang (src/gleam_stdlib.erl)

• Base64: bit_array_base64_encode/2, base_decode64/1
• Base16: base16_encode/1, base16_decode/1

JavaScript (src/gleam_stdlib.mjs)

• Base64: encode64(bit_array, padding), decode64(s)
• Base16: base16_encode(bit_array), base16_decode(s)

Public Gleam API (consistent and not the problem):

• base64_encode/2, base64_decode/1
• base16_encode/1, base16_decode/1

Motivations

• Decrease friction when searching, reviewing, or extending FFI code.
• Avoid one-off decisions (e.g. bit_array_base64_encode) that are hard to remember.
• Allow future additions (base32, base85, etc.) to adopt a consistent naming convention.

Proposal

Decide on a single convention for FFI function names across all bases and both targets. I came up with two options.

Option A - Short Verbs

Adopt an encodeNN / decodeNN naming convention on both targets:

Erlang:

• base64 → encode64()/decode64()
• base16 → encode16()/decode16()

JavaScript:

• base64 → encode64()/decode64()
• base16 → encode16()/decode16()

Option B - Explicit Base Prefix

Unify to base_encodeNN / base_decodeNN on both targets:

Erlang:

• Change bit_array_base64_encode() → base_encode64()
• Keep base_decode64()
• Change base16_encode() to base_encode16()
• Change base16_decode() to base_decode16()

Javascript:

• Change encode64() to base_encode64()
• Change decode64() to base_decode64()
• Keep base_decode16()/base_decode16()

Migration Plan (if accepted)

1. Implement chosen convention across Erlang and JavaScript FFI.
2. Keep old FFI names as aliases for one release cycle (deprecated).
3. Update tests and docs accordingly.
4. Document the convention for future base encoders (e.g. base32/base85/base58).

Acceptance criteria

1. One documented convention selected.
2. All base encoders/decoders (16/64) follow it in both Erlang and JavaScript.
3. CI green; no public Gleam API changes required.
4. Provide temporary aliases to avoid any breakage. (maybe?)

[lpil]

Thanks for investigating this, very thorough work! Your points seem good to me, would you like to make a PR?

The FFI functions are not a public API, so we can change them at any time. No need to deprecate them or anything like that.

[xikaos]

Can do! Thanks for the feedback! 🙏