const std = @import("std");
var u01: bool = true; // error: name shadows primitive 'u01'
pub fn main() !void {
std.debug.print("{}\n", .{@sizeOf(u01)}); // error: primitive integer type 'u01' has leading zero
}
u0/i0 are legal types, so you need to allow 0s starting the number part of an integer type.
Disallowing leading zeros makes sense from a readability point of view (each primitive number type has one way to write it) and from a parsing point of view (exit early if the number portion starts with a 0 and contains more digits).
Remember that Zig (as of 15.2) allows primitive integer types up to u65535. With that in mind, making uN with an invalid number an error, instead of parsing it as an identifier, is probably the right choice.
Will future you remember that u55555 is a primitive type but u66666 is an identifier? What if the range accepted by Zig’s big numbers increases in the future and u66666 suddenly becomes an integer primitive?
Not sure if it’s intended (only the team can answer that), but I think the worst crime here is an unhelpful error message. Ideally the first error should tell you that u01 isn’t an integer type but that u01 still isn’t a valid identifier.
e.g.
error: name 'u01' invalid due to ambiguity with primitive integer type names
5 Likes