On Vector Syntax

Personally, I would prefer an implementation where vectors are declared in the manner somewhat like that of a struct:

const Pixel = vector(f32) { r, g, b, a };
const p: Pixel = .{ .r = 0, .g = 0, .b = 0, .a = 1 };
p.a = 0.5;

Elements in a vector generally have specific meaning. For a pixel, the first element is the red channel, the second is the green channel, and so on. Vectors are generally not used in the same manner as arrays. They aren’t collections of things of the same type. The ability to reference elements by name is very helpful.

Potentially we can have convenient syntax like this:

p1.rgb = p2.rrr; 

Which sets the first three vector elements of p1 to the first element of p2.

EDIT: Here’s perhaps a better example. Instead of this:

pub const Vector = @Vector(3, f32);

pub fn cross(v1: Vector, v2: Vector) Vector {
    const p1 = @shuffle(f32, v1, undefined, @Vector(3, i32){ 1, 2, 0 }) * @shuffle(f32, v2, undefined, @Vector(3, i32){ 2, 0, 1 });
    const p2 = @shuffle(f32, v1, undefined, @Vector(3, i32){ 2, 0, 1 }) * @shuffle(f32, v2, undefined, @Vector(3, i32){ 1, 2, 0 });
    return p1 - p2;
}

We would have something like this:

pub const Vector = vector(f32) { x, y, z };

pub fn cross(v1: Vector, v2: Vector) Vector {
    return v1.yzx * v2.zxy - v1.zxy * v2.yzx;
}
1 Like

In the topic from this one was split I was talking about u32/i32 vs u32/s32 (which are builtin types) and nothing more. But @Vector(N,T) is not a type, it’s a tool for creating types (compiler builtin that returns a type) and you can give any name you want to the types that it created.

It is, in fact, a type. A parameterized type, yes, but that’s a type of type. As it were.

Kind of, not really:

const v4u32 = @Vector(4, u32);

test "vector synonym" {
    const v: v4u32 = .{ 1, 2, 3, 4 };
    _ = v;
    std.debug.print("type name is {s}\n", .{@typeName(v4u32)});
}

Prints "type name is @Vector(4, u32)".

You can define synonyms for any type you’d like, but they also have names, which won’t change.

1 Like

It’s just means that a type created with @Vector(4, u32) has the same name, as a call to compiler, that generated it. And yes, all synonyms inherit that original name, ok. Type name is just a string and it can be anything.

It’s not. Andrew Kelley has said repeatedly he’s willing to make completely breaking changes before 1.0. Zig is NOT done, and it is a moving target. It’s been really stable for a while because it took a long time to get the self-hosted compiler to the level that the C++ version was at, and there’s also been a lot of effort dedicated to incremental compilation, self-hosted backends, the type Intern Pool, async (although those efforts didn’t pay off yet), and, of course, trying to fix all the regressions and breaking changes that LLVM introduces with every single release.

Is it likely to completely change? Of course not. There are a lot of things that Zig seems to get right. But the reason that they can’t be overturned is not for compatibility or convenience reasons, it’s because it’s already the way it should be.

2 Likes

I believe the philosophy of “no operator overloading” is exactly what you said. All overloads are defined by the language, it’s not a guarantee that a particular operator has precisely one set of semantics. The perspective on readability is that + can’t be something outside of what I saw in the language docs. I know it doesn’t allocate. I know it’s going to give me some number of add instructions based on what type we’re dealing with. It’s either two’s complement, floating point, or vectorized addition. Nothing else.

If you want changes though, I’d read through the old issues, and if you write a high quality proposal with ideas that haven’t been considered yet, it will be considered.

1 Like

Ok, good to know. I knew there’s been a moratorium on new proposals for nearly a year now, from a newcomer’s perspective that looks like the kind of thing that a language which is stabilizing toward 1.0 might do. If Zig froze in its present form it would be a very good language, as far as I’m concerned.

In that case I might open up a proposal on getting rid of the vector special case, once new proposals are being accepted again. That would remove complexity from the language, and it shouldn’t cost anything in terms of generating good code.

Meanwhile I’ll just keep learning and using the language. Having a good time with that so far.

That moratorium is there to stop “drive-by proposals”. Andrew doesn’t want people outside the Zig community to come in and submit low-effort issues telling him to add their favorite C++ feature that’s already been considered and rejected in the past (or accepted, but not added yet and they didn’t even bother to research the history). If you do your research and make a well-reasoned case for something not yet considered, you can submit a proposal. But if you just write two sentences telling them to change the syntax a little, you might get a “drive-by denial”.

3 Likes

Good to know. Think I’ll stick with using the language, reading up on the history of the issue board, studying the compiler implementation etc. For now anyway. Tends to lead to better proposals.