zig
zig copied to clipboard
Renaming `@xtoy` to `@YfromX`
I apologize in advance for such huge breaking changes.
"zig fmt" automatically renames @stuffToStuff to @stuffFromStuff, but you can also invoke simple sed stuff like:
sed -i 's/@ptrToInt/@intFromPtr/g' whatever.zig
Also renames std.meta.intToEnum to std.meta.enumFromInt, for simmetry. See also https://github.com/ziglang/zig/pull/15580.
Closes https://github.com/ziglang/zig/issues/6128.
eh new conflict right before
eh new conflict right before
Yeah, such things are abit of a bummer: #14186 #14726.
It's green! And second conflict
Thinking about it:
- IMHO it makes source code skimming and reading easier due to:
- reasons from original issue
- fact that "most of the builtins starting with a name of type returns this type":
@intFrom*and@intCastall returns some integer,@ptrFromIntand@ptrCastboth returns some pointer etc. (except@err*since it has@errorNamewhich returns a string representation):
// It is a strange example but anyway.
const suitable_universe = (@intFromEnum(player1.universe) +| 2) == (@intFromEnum(player2.universe) -| 3);
// No need to read full line, at this point already know that "a" and b are some float
// const a = @float???
// const b = @float???
// ^^^^^^
const a = @floatFromInt(f32, @intFromBool(suitable_universe));
const b = @floatCast(f64, a * 2);
// Old version:
const a = @intToFloat(f32, @boolToInt(suitable_universe));
const b = @floatCast(f64, a * 2);
- But it makes writing this code harder:
// Previously, you could've start writing your code by doing smth like this:
// const a = @intTo???(!!!, 1024);
// const a = @intTo
// It gives you some time to warmup and to think "what type do I want to get?",
// also, editor (most? of them) helps you to choose from auto-completion list.
// Now, you need to choose "output" type right at the beginning,
// and this action slows you down a bit.
// IDK if editors help you to auto-complete function from the end,
// I never used that option.
// Same when you edit this line to change "output" type again.
const a = @floatFromInt(f32, 1024);
// This does not affect "@intCast" and similar builtins,
// since one chooses them when both types are of same "family".
Please note also #5909 which is accepted and affects your examples above.
Regarding reading vs writing, the Zig language is all about reading and not writing, so there is an easy answer to this question. Reading wins.
However, if you are not personally in favor of this change, then please don't force yourself to do it.
Please note also #5909 which is accepted and affects your examples above.
Regarding reading vs writing, the Zig language is all about reading and not writing, so there is an easy answer to this question. Reading wins.
However, if you are not personally in favor of this change, then please don't force yourself to do it.
Well, I am in favor of this change, it was just "for your information" to see if you'd change your mind (and I would not mind, it was a little effort with rename-and-test), and I'm looking ahead for merging :)
Thwarted again! Let's try another run.
(I am taking care of it)
Thwarted again! Let's try another run.
(I am taking care of it)
Thanks again! Was it because of security reasons (zig1.wasm update that is initiated by non-core team member)?
It was yet another conflict that occurred while the CI was running