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));
    }