fn MultiplyType(comptime Self: type, comptime Other: type) type {
if (Self{}.height != Other{}.height) {
@compileError("matrices with different heights provided");
}
return Matrixx(Other{}.width, Self{}.height);
}
pub fn multiply(self: @This(), other: anytype) MultiplyType(@This(), @TypeOf(other)) {
const new = MultiplyType(@This(), @TypeOf(other)){};
// do multiply op on new
return new;
}
#Matrix thread from #zig
1 messages · Page 1 of 1 (latest)
it's Self{}.height the Self is type
might need to put inside parenthesis maybe (Self{}).height
yes that was it
you can also give the matrix type pub const Height = height; decl so you can do also Self.Height skipping the need of doing {} :P
is (self{}) just casting it to its data or something?
{} makes instance of the type
oh
() is only needed to disambuage the grammar for compiler
and that only works because width and height are comptime
because its part of the type
do i need to set the value of buffer?
oh
i think i can just set it to undefined in the defenition
so its undefined at comptime i think???
even though the field isn't comptime
maybe better would give the struct the pub const as I mentioned earlier
the undefined default value is not good pattern
return struct {
pub const Width = width;
pub const Height = height;
...
then you can Self.Height, Other.Width and so on
without having to instantiate the type or set .buffer to undefined every time or worse as default value
as general rule it's almost never good idea to have undefined as default value but ask for the programmer instead to set something to undefined by themselves at calling level
in the multiply function for example I would set it to undefined manually:
pub fn multiply(self: @This(), other: anytype) MultiplyType(@This(), @TypeOf(other)) {
const new: MultiplyType(@This(), @TypeOf(other)) = .{ .buffer = undefined };
// do multiply op on new
// since buffer is undefined, make sure you fill it completely!
return new;
}
keep both the comptime field and the pub const field
oh
or @TypeOf(self).Width if you just want one
the declarations will be part of the type while fields will be part of the instance
oh okay nice
they can have the same name as the fields
so i think thats fine to have it twice
similarily when you call method it's just syntax sugar for Type.foo(type, ...);