Docs reference integer types (int128/256/512, uint128/256/512) and suffixes (i128/i256/i512, u128/u256/u512) that the compiler does not implement

[davidfrogley]

Summary

The integer documentation, examples, and TextMate grammar describe seven signed and seven unsigned integer widths (8/16/32/64/128/256/512) plus matching literal suffixes. The compiler only implements the four standard widths plus the platform-dependent aliases:

• Signed: int8, int16, int32, int64, int
• Unsigned: uint8, uint16, uint32, uint64, uint

Code copied from the docs that uses int128/int256/int512/uint128/uint256/uint512 or the suffixes i128/i256/i512/u128/u256/u512 fails at name resolution or literal parsing.

Compiler reality (source of truth)

Rux/Include/Rux/Type.h:17-50 — TypeRef::Kind defines exactly these integer enumerators:

Int8, Int16, Int32, Int64,
UInt8, UInt16, UInt32, UInt64,
Int, UInt,        // platform-dependent (64-bit on x64, 32-bit on x86)

No Int128 / Int256 / Int512 / UInt128 / UInt256 / UInt512 exist anywhere in the compiler.

Repro

let a: int128  = 1;     // unknown type
let b: int256  = 1;     // unknown type
let c: int512  = 1;     // unknown type
let d: uint128 = 1;     // unknown type
let e: uint256 = 1;     // unknown type
let f: uint512 = 1;     // unknown type
let g = 1i128;          // unknown suffix
let h = 1i256;          // unknown suffix
let i = 1i512;          // unknown suffix
let j = 1u128;          // unknown suffix
let k = 1u256;          // unknown suffix
let l = 1u512;          // unknown suffix

All twelve declarations should compile per the docs; none do.

Every doc/asset that needs editing

Web/src/docs/types/int.md

• L9 — overview: "int8 through int512 and uint8 through uint512".
• L18-26 — signed types table; rows for int128, int256, int512.
• L28 — "int128, int256 and int512 are emulated in software…".
• L36 — bullet: "int128 — extended-precision intermediate results, UUID arithmetic."
• L37 — bullet: "int256 / int512 — cryptographic big-integer arithmetic, …".
• L43-51 — unsigned types table; rows for uint128, uint256, uint512.
• L59 — bullet: "uint128 — IPv6 addresses, GUIDs, 128-bit hash values."
• L60 — bullet: "uint256 — cryptographic hashes (SHA-256 output), Ethereum addresses."
• L61 — bullet: "uint512 — SHA-512 output, large-integer cryptographic primitives."
• L162-164 — signed-suffix table rows i128, i256, i512.
• L175-177 — unsigned-suffix table rows u128, u256, u512.
• L421 — recommendation: "Avoid int128 and wider in hot loops."
• L429 — note: "int128 / uint128 on common 64-bit targets…".
• L431 — note: "int256, int512, and their unsigned counterparts are software-emulated everywhere."

Web/src/docs/lexical/literals.md

• L14 — suffix list: "i8, i16, i32, i64, i128, i256, i512, u8, u16, u32, u64, u128, u256, u512".
• L21-23 — example block: -16u128 // int128, -16u256 // int256, -16u512 // int512 (also wrong family: a u-suffix produces an unsigned type, not intN).
• L28-30 — example block: 255u128 // uint128, 255u256 // uint256, 255u512 // uint512.

Web/src/examples/Int.rux

• L6-8 — int128, int256, int512 declarations.
• L15-17 — uint128, uint256, uint512 declarations.

(L1-5, L9-14, L18-29 are correct and should stay.)

Web/.vitepress/grammars/rux.tmLanguage.json

• L147 — decimal-number regex includes nonexistent integer suffixes: (…|i128|i256|i512|…|u128|u256|u512)? — should drop the 128/256/512 entries for both i and u.
• L169 — hex-number regex: same nonexistent suffixes; same fix.
• L179 — octal-number regex: same nonexistent suffixes; same fix.
• L189 — binary-number regex: same nonexistent suffixes; same fix.
• L547 — integer type-name regex: \b(int|int8|int16|int32|int64|int128|int256|int512|uint|uint8|uint16|uint32|uint64|uint128|uint256|uint512)\b — should drop the 128/256/512 names for both int and uint.

Web/src/docs/types/char.md

• L75 — passing reference: "implicit conversion to u64, u128, etc. is not permitted." u128 is not a real type; reword (e.g., drop the example, or replace with uint32/uint64).

Suggested fix

Trim docs/examples/grammar to match the compiler — int{8,16,32,64}, uint{8,16,32,64}, plus int/uint, with suffixes i{8,16,32,64,} and u{8,16,32,64,} only. If extended-precision integers are on the roadmap, gate those sections behind a "Planned" / "Not yet implemented" callout instead of presenting them as available.