Renaming @xtoy to @YfromX

[BratishkaErik]

I apologize in advance for such huge breaking changes.
"zig fmt" automatically renames @xToY to @yFromX, 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 #15580 dropped on @andrewrk 's request.
Closes #6128.

[BratishkaErik]

eh new conflict right before

[matu3ba]

eh new conflict right before

Yeah, such things are abit of a bummer: #14186 #14726.

[BratishkaErik]

It's green! And second conflict

[andrewrk]

Also renames std.meta.intToEnum to std.meta.enumFromInt, for simmetry. See also #15580.

Can you please omit this change from the patch? This way, this will be a breaking change, but one that can be completely migrated using zig fmt. Let's handle intToEnum separately please (same logic from the linked issue applies here with regards to 1 break and not 2).

Other than this, I think this is a good time to make this breaking change. Thanks!

[BratishkaErik]

Thinking about it:

1. 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 @intCast all returns some integer, @ptrFromInt and @ptrCast both returns some pointer etc. (except @err* since it has @errorName which 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);

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".

[andrewrk]

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.

[BratishkaErik]

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 :)

[andrewrk]

Thwarted again! Let's try another run.

(I am taking care of it)

[BratishkaErik]

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)?

[andrewrk]

It was yet another conflict that occurred while the CI was running