You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Zig the compiler prevents you from passing structs (and other potentially big data) to procedures by values. This is good, cause then we avoid large copies. This does however have the side effect that all generic code have to pass &const T around, to ensure that the code is truly generic.
Now, let's say that I have some procedure for lessThan on strings ([]const u8). It would look something like this:
And I have a slice of strings ([][]const u8). I can't use my lessThan procedure for generic procedures like insertionSort, because it requires procedures of type fn(&const T, &const T) -> bool or fn(&const []const u8, &const []const u8) -> bool for strings specifically. This means, we have to write an ugly wrapper function whenever we wanna use "pass by value" procedures with generic procedures.
This might not be a problem, and we decide that this is indeed how it should be. I do however think this needs to be discussed before deciding on "the standard way" of writing generic procedures.
Let me kick the discussion of with one way of dealing with this. In Zig, we can actually write a user space procedure that can decide whether a type can be passed by value. With this a procedure can also be written to take a type, and return a type that can be passed to a procedure (see types.zig for implementation).
With these procedures insertionSort can now have this signature:
In Zig the compiler prevents you from passing structs (and other potentially big data) to procedures by values. This is good, cause then we avoid large copies. This does however have the side effect that all generic code have to pass
&const T
around, to ensure that the code is truly generic.Now, let's say that I have some procedure for
lessThan
on strings ([]const u8
). It would look something like this:And I have a slice of strings (
[][]const u8
). I can't use mylessThan
procedure for generic procedures likeinsertionSort
, because it requires procedures of typefn(&const T, &const T) -> bool
orfn(&const []const u8, &const []const u8) -> bool
for strings specifically. This means, we have to write an ugly wrapper function whenever we wanna use "pass by value" procedures with generic procedures.This might not be a problem, and we decide that this is indeed how it should be. I do however think this needs to be discussed before deciding on "the standard way" of writing generic procedures.
Let me kick the discussion of with one way of dealing with this. In Zig, we can actually write a user space procedure that can decide whether a type can be passed by value. With this a procedure can also be written to take a type, and return a type that can be passed to a procedure (see types.zig for implementation).
With these procedures
insertionSort
can now have this signature:And now,
insertionSort
can take mylessThan
procedure without any wrapper.This solution does complicate the generic code a little, as one would have to call the
getValue
to use values passed withPass
.The text was updated successfully, but these errors were encountered: