Proposal: Rename comptime_int and comptime_float to anyint and anyfloat

[ghost]

EDIT: See @RaphiJS6-13 below for a better idea.

Minor part of #5895 that was not moved out following the post-#7396 purge. Remedying that now.

When a function takes an argument or a struct has a field of type comptime_int or comptime_float, the declaration is already annotated with comptime. A second comptime in the type name just seems repetitive. Removing it would have psychological benefits as well: the types seem less like arcane compiler details and more like a normal, everyday part of code, which they are, and makes it more obvious why every literal requires a type (status quo: "What's the type of this? It's an int. All looks normal. compile error Excuse me? flips through docs Oh, yeah, it's a comptime_int. Right."; this proposal: "What's the type of this? It's an int. Oh, yeah, that's a comptime-only type, isn't it? Better coerce it.").

There is precedent for this: type, anytype and such are comptime-only (or have restrictions on their use), and do not have any special markings indicating this. Continuing this pattern with int and float I believe will be a valuable step toward normalising comptime in the minds of users. I think of it like this: comptime_int and comptime_float sound like specialsed, arcane types, but they're actually in a way the most basic numeric types in the language, the types which coerce to all others. They should have suitably "basic" names.

[tecanec]

What about sizeless_int and sizeless_float? It's easy to tell that type is comptime-only, because there's an obvious reason why: zig uses static types. int and float don't have that benefit, because runtime ints and floats exist, and in most languages, int and float are runtime types. sizeless_int and sizeless_float gives us a clear reason why they are comptime-only, and it makes it clear that number literals would have those types.

[ghost]

type does not need an explicit comptime_ prefix, because types are always comptime in Zig. Numeric types, on the other hand, have both comptime and runtime variants, so it makes sense to distinguish them.

I think people will spend more time trying to figure out what's wrong with their fn foo(x: int) int { ... } definition, than they will spend being confused by comptime_int in error messages.

[RaphiJS6-13]

What about anyint and anyfloat? It's more intuitive, and is consistent with anytype, anyframe, and anyerror.

Edit: anytype might be renamed, see #5893.

[ghost]

That's good, actually. I like that better.

[J-MR-T]

What about anyint and anyfloat? It's more intuitive, and is consistent with anytype, anyframe, and anyerror.

(any time I talk about ints in this comment, read ints or floats)

Naming them after these makes the whole any prefix less consistent in my opinion, not more. You can't declare a local variable anytype, but you can declare it comptime_int, because that's actually a type (although just comptime), as opposed to anytype.

Of course, this is why #5893 exists, but the suggestion above still implies anyint would fit better with anytype. To be honest, I don't see a need to rename comptime_int, especially not if it makes error messages about integer literals that are not coerced less clear. "anyint is a problem? Shouldn't I be able to use anyint if I don't care which int I need?". It's the same problem as with anytype, just from the other direction, which is why I would suggest to avoid introducing any more of this any- confusion.

[nektro]

You can't declare a local variable anytype

this the only any* that this applies to. anyframe, anyerror, *anyopaque can all be instantiated.