Repository navigation
Remove FFI type aliases while it's still experimental #64848
Description
Activity
- changed the title
[-]Remove FFI type aliases while it's still experemental[/-][+]Remove FFI type aliases while it's still experimental[/+]on Jul 30, 2026 Feel like this should apply to the
ffi.typesenum as well – it's pointless providing eg.ffi.types.INT_32if all the documentation tells users to use'i32'instead.IMO this should either be made the canonical way to pass types (like eg. the
quic.constants.ccenum), or removed.Reacted by Soul Lee- added a commit that references this issue
on Aug 2, 2026 I don't agree on this issue
People can just remember their most loved convention (i8 vs int8 and equivalent) but this way we are friendly with people coming from pretty much all languagues hierarchy. No real cognitive load here.When users prefer different options, I think that software should support all and let users choose their favorite.
Personally, I prefer longer names likeint32overi32as it gives clarity and is less likely to create confusion.We can retain aliases, but designate and prominently document one canonical spelling for each type in documentation?
For example:
Supported type names:
int8uint8int16uint16int32uint32int64uint64float32float64
Alternative spellings
i8forint8u8foruint8i32forint32u32foruint32f32forfloat32f64forfloat64
WDYT?
I'm fine for the documentation. Let's also retain
strandptras aliases.Reacted by Trivikram KamatOne thing I'm still wondering about is cases like
bool/uint8andbuffer/arrayBuffer.Unlike
u8/uint8, these seem a bit different semantically from a user's perspective.
Maybe they're worth discussing separately from simple alternative spellings.Reacted by Caleb Everett
What is the problem this feature will solve?
node:ffi was introduced with synonyms for the same types
While this may be convenient for folks that are familiar with the different names, it also adds mental overhead - developers need to confirm if 'char' and 'u8' mean the same thing or are subtly different.
There were a few bugs that are kindof related to this
ffi.types.FLOAT_32was added it's value wasfloat32which wasn't a supported alias, so now there's three ways to spell float 32.bufferandarraybufferare also synonyms but are different lines in the docscharis listed on the same lines as u8 and bool but it is not a synonym (it varies by platform)cc @nodejs/ffi
What is the feature you are proposing to solve the problem?
We should remove each synonym and keep one spelling for each distinct type.
I'm not opinionated on which spelling we prefer, I think the uint8 style agrees with
ffi.typesand the access helpers (getUint8).We should do this now while the module is experimental. WE can always add more names in the future, but removing them after the module is stable is harder.
What alternatives have you considered?