-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: allow @splat
for arrays
#20433
Comments
Would (copied from issue): // a default-initialized struct
const Bla = struct {
x: i32 = 0,
y: i32 = 0,
z: i32 = 0,
};
// and another struct with an embedded array of those default-initialized items:
const Blub = struct {
items: [4]Bla = [_]Bla{ .{} } ** 4,
}; With this change could Blub could be initialized like this? const Blub = struct {
items: [4]Bla = @splat(.{}),
}; And then independent of struct support, could it be used to default-initialize the rest of an array using concatenation if there are some number of unique values? const pix_count = 4;
var pixels0: [pix_count]u32 = .{1,2} ++ @splat(0); // 1, 2, 0, 0 (main use-case)
var pixels1: [pix_count]u32 = .{1} ++ @splat(undefined); // 1, undefined, undefined, undefined (supports undefined values)
var pixels2: [pix_count]u32 = .{1,2,3,4} ++ @splat(0); // 1, 2, 3, 4 (supports length of zero) |
Yep, absolutely. The behaviour of |
Could this also improve a codegen being a builtin? |
I imagine it would be identical and |
Why on earth would |
Unless the constant 42 here is 0, zig currently likes to insert the number into the binary N amount of times, worse is that the array here is even never used as it gets overwritten immediately. It seems 0 is special cased and compiles into memset. |
0 is not really special, memset is used whenever the 4 bytes of the int are all the same, see https://godbolt.org/z/sEcjncfG8. |
@Vexu, could you elaborate on your thumbs-down? I ask only because I've not seen an argument against this so far and would like to be aware of potential downsides to this proposal. |
I just don't like the idea of expanding a SIMD specific builtin for what looks to me like syntax sugar purposes that doesn't even fully replace |
Sorry, I should be clearer: it's not intended to fully replace I personally don't see a problem with expanding this builtin, because it's very obvious what the expansion does, and I don't see a way it could lead to any confusion, harm readability, etc. |
I can see there being some confusion that the other vector builtins ( |
Resolves: ziglang#20433
Background
It is quite common to want to initialize arrays to a fixed constant value. Today, this is typically done with the
**
operator as follows:However, this usage is a little awkward: the array length is specified twice! In this case, we could omit the type annotation:
However, this makes it less clear what the type of
pixels
is, and is not consistent with a general preference for type annotations over explicitly-typed expressions. The situation gets even worse in the case of nested arrays:This is really unpleasant. In both cases, the initialization expression is quite tricky to understand at a glance; plus, in the former case there's a lot of repetition, and the latter case is borderline unreadable.
When initializing vectors to a fixed value, we already have a solution: the
@splat
builtin.However, no equivalent exists today for arrays. This awkwardness leads to people reaching for
std.mem.zeroes
in many cases, which we definitely want to discourage.Proposal
Allow
@splat
to initialize arrays. Nothing else about the builtin changes; the way it works is fairly obvious. The above examples look like this:There's really nothing else to say here. This is a trivial expansion of an existing syntax form in an intuitive manner. The meaning of the newly-allowed code is obvious, and improves readability while discouraging questionable usages of
std.mem.zeroes
.The text was updated successfully, but these errors were encountered: