The C standard effectively can’t add new types without the “_t” suffix, so they’re stuck with limitations that a brand new language won’t have.

Can't they add a new header file?

What if a library API needs to include this new header because it wants to use the new typedefs in its API declarations but your own code (which needs to include the library header) also has its own 'u8' typedefs?

(PS: it's probably ok because C compilers seem to accept redundant typedefs)

It sounds like you got some refactoring to use since you didn't namespace your own core types?

I think that "namespacing" basic types such as u32 is completely unecessary.

In what world would an u32_MYLIB would be different than an u32_SOMELIB?

Basic types are common enough.

The preprocessor doesn’t know that u32 defined in foo.h is the same type as u32 defined in bar.h. So you’ll get an error when importing both.

If C made this change, it could also make it legal to redefine u32 etc as appropriate integer types any number of times without erring.

foo.h defines i64 as “long” and bar.h defines it as “long long”. Now what?

This would break legacy code. I had one employer with a bool type that was a 32-bit integer because of obscure alignment issues. This is why _Bool exists and the bool typedef has to be brought in explicitly with stdbool. You can't just go and usurp popular short type names. The standard reserved *_t and _[A-Z].+ for this purpose. People have been writing portable code with the expectation that future standards aren't going violate that promise and break things.

This is just one of the reasons that new languages that dispense with outdated assumptions and insted make assumptions more suitable to our times are a good thing. C and C++ are really old and some things can not be fixed with libraries.

C doesn't have namespaces.

The only sane way to deal with name collisions is either to use C stdlib types in library APIs (e.g. uint8_t), or use a library specific prefix (e.g. mylib_u8) - which is of course even more awkward than just using the standard uint8_t.

A prefix and a namespace aren't really that different in practice.

They are different. Namespaces are syntactically enforced and you can opt-in or out to names. To have syntactically validated qualified access.

Naming might go well and have the same utility, but you never know what evil things are going on in all those headers, redefining each other's symbols and yours.

You seem to be focusing on specific problems with C/C++. I don't really care about that, all I'm saying is that prefixing names are equivalent to placing them within a namespace, in practice, and theoretically come to think of it. You can easily define a bijection between namespaced symbols and prefixed symbols. Requiring the full prefixes are simply a tad more verbose, essentially equivalent to using a fully qualified name for symbol.

Same reasoning applies to new keywords.

They added new keywords just fine, even if it needs a trasition phase to go through them.

do you mean just to save the _t and int substrings, over and over? (if so, i agree)

D uses byte, short, int, long for i8, i16, i32, i64, and ubyte, ushort, uint, and ulong for the unsigned versions. After 5 minutes with the language there is no longer any point to emphasizing the number of bits. Besides, they're just easier to touch type.

I think that trade off made more sense twenty years ago than it does today. So it's understandable that D did this, but doesn't make it a good choice for Zig.

Zig programmers don't need to keep talking about types, so the type (and thus in this case its size) is getting mentioned mostly when that matters, e.g. API boundaries.

Not sure if I parse your argument right, but there's lot of cases when one would care how wide specific integer type is. Especially in the code that works with data in bulk (as in millions/billions of data objects), where not wasting bits really pays off.

Sure there is: when I’m parsing or serializing something it’s pretty important I know what size something is.

The size of `byte` is fixed at 8, `short` 16, `int` 32, `long` 64. There is no ambiguity or uncertainty about it.

At that point, why not just call them i/u8/16/32/64? If the sizes are fixed anyway, why come up with different names for them, especially when almost all of the times you would want to select a different integer type is specifically because of how many bits wide it is? (otherwise, surely you would just use the machine word size?)

Good question.

1. After 5 minutes, you know what sizes they are, and don't need reminding.

2. Easier to touch type.

3. They're just aesthetically more pleasing to the eye.

4. The names aren't really different, they follow the most-used (by far) sizes on C.

5. It's easier to say and hear them. I can say "int" when talking code with someone, instead of "eye-thirty-two".

6. I'm guessing it may be easier for a visually impaired coder with a screen reader.

Just be honest with yourself and say that you subjectively like it better that way, as it grew on you.

There is nothing wrong with that reasoning. Also, there will never be a language which is perfect in every conceivable way, this is such a minor difference that if someone chooses a language over this alone, they are not being reasonable.

A language is nearly all about subjective choices.

Eh the `ix`/`ux` is just as short and more descriptive. D just clings to C-like design to a fault sometimes.

> Besides, they're just easier to touch type.

These two styles are equally fine for touch typing… as long as you know how to touch type (not just how to touch type on the alphabet rows).

But Zig lets you use arbritary number of bits... you can write `i4` for example, or `u120` or whatever, which is a pretty great advantage.

True, but can you create a pointer to a 4 bit type? I tried to make that work in D at one point, and wound up abandoning it.

D allows 4 bit types using conventional bit fields (but you can't take a pointer to them).

Yes:

    const std = @import("std");
    const expectEqual = std.testing.expectEqual;

    test "u4 is 1 byte" {
        try expectEqual(1, @sizeOf(u4));
    }

    test "u4 is 4 bits" {
        try expectEqual(4, @bitSizeOf(u4));
    }

    test "u4 is 1-byte-aligned" {
        try expectEqual(1, @alignOf(u4));
    }

    test "pointers to u4 work like any other pointer type" {
        var foo: u4 = 10;
        const foo_p = &foo;
        try expectEqual(@as(u4, 10), foo_p.*);
        foo_p.* = 7;
        try expectEqual(@as(u4, 7), foo);
    }

Packed structs are Zig's replacement for bit fields:

    const std = @import("std");
    const expectEqual = std.testing.expectEqual;
    
    test "bool has a bit size of 1 bit, a size of 1 byte, and an alignment of 1 byte" {
        try expectEqual(1, @bitSizeOf(bool));
        try expectEqual(1, @sizeOf(bool));
        try expectEqual(1, @alignOf(bool));
    }
    
    test "in a regular struct, fields are aligned to their natural alignment..." {
        const Natural = struct {
            read: bool,
            write: bool,
            exec: bool,
        };
        try expectEqual(3, @sizeOf(Natural));
        try expectEqual(1, @alignOf(Natural));
    }
    
    test "...unless otherwise specified" {
        const TwoByteAligned = struct {
            read: bool align(2),
            write: bool align(2),
            exec: bool align(2),
        };
        try expectEqual(6, @sizeOf(TwoByteAligned));
        try expectEqual(2, @alignOf(TwoByteAligned));
    }
    
    test "in a packed struct, fields occupy exactly their bit size" {
        const Packed = packed struct {
            read: bool,
            write: bool,
            exec: bool,
        };
        try expectEqual(3, @bitSizeOf(Packed));
        try expectEqual(1, @sizeOf(Packed));
        try expectEqual(1, @alignOf(Packed));
    }

Having spent a lot of time porting 32bit system code to 64bit, I developed a dislike for these explicit types. It's a slippery slope to hard code your bitness with people making assumptions where size_t or pointers fit.

Now maybe if you're already 64bit that's fine (it's unlikely that we'll ever need 128bit, and code is unlikely to grow down), but for anything starting smaller it's a pain.

Just because your code compiles on a new platform doesn't mean the prior assumptions of the prior behavior of the types remains valid.

But it should, and that's what stricter typing can help with.

People are already working on a 128bit Linux kernel.

The sizes of floating point are growing "apart" in the AI space. Who's to say what might happen with sizes of types. Maybe it's great to use mostly u8 if you're controlling a worldwide asynchronous networked megacomputer.

Huh?

Zig, like Rust, has two kinds of "primitive" numeric types, the kind which are an explicit size in bits (u8, i16, f64 and so on) and then the word size ones (isize, usize), which are whatever size is suitable for your target machine.

C gets this all muddled because it has named primitive numeric types but their meaning is imprecise, and then it uses a typedef to assign one of these (but you don't know which one) as the native word size. So maybe long is the same as your size_t, and C will just assume you know what you're doing when you write a long where you need a size_t - thus making your code non-portable.

They’re better than implicit assumptions that int is 32 bits.

What I'm really waiting for is zig support for custom range ints https://github.com/ziglang/zig/issues/3806

Also minor nitpick I have is that the interval/range syntax in zig is pretty confusing as it can be both inclusive and exclusive depending on context. Swift does it imo better by ... being inclusive and ..< exclusive

I was surprised they didn’t copy Swift on this. It seems just obviously better than two dots.

Groovy has had that syntax for much longer than Swift has existed... Groovy normally copies features from Ruby/Python/SmallTalk so I would think one of those are the source for this syntax.

Most of the time you want to use something like size_t anyways.

It is couple of lines of typedef, what’s the big deal.