THIS IS NOT A DRILL
anygate coming in 0.17.0, to a Zig near you!
7 Likes
Anytype is getting
OMG OMG OMG It’s finally happening!!
renamed
…..Oh.
7 Likes
anytime… now
2 Likes
You thought you were getting infer T, but it was me, anyval!
6 Likes
Recently, Zig has really been undergoing some profound changes. The removal of the result location pointer also surprised me.
2 Likes
Don’t worry, automatic migration via zig fmt will save us all!
2 Likes
I just wanted to come and start the bike-shedding over whether or not anyvalue would have been the better choice. 
2 Likes
I’ll start then: it’s as bad as anytype imo.
The name anyerror makes sense because it’s any error from any error set. But anytype most often shouldn’t be of any type, nor anyval arguments should hade any value.
It’d be better described with generic, @Generic(), or infer T.
3 Likes
My personal choice would have been infer, auto, dynamic, or something along those lines, but to be honest, I never had any problem with it being anytype in the first place. Whether they use anyval or anyvalue, I don’t see how that is an improvement over any of them. In fact, I think anyval is the worst possible choice that could have been made of the choices being discussed, including just leaving it as anytype.
I frankly never saw the point being made by the OP of the issue, they seemed to be reading too deep into the semantics until they confused themselves. All that said, the issue is insignificant to me, I really don’t care what they call it, i will accept whatever they use and avoid using it as much as possible just the same. Hopefully someday we look back and laugh at the debate over the naming of this legacy part of the language that no longer exists.
3 Likes
Doesn’t anytype cause the thing using it to monomorphize over the type? Or have I been not understanding it this entire time?
Yeah, a function with an anytype argument, just like a function that takes a type as a comptime-known argument, will become a generic function which is recompiled for each unique type passed into it.
anyvalue : anyval :: anyerror : anyerr 
7 Likes
The more I think about it, the more I think @Generic is the right choice. Because unlike anyerror it’s not an actual type. It’s a special keyword only allowed in a particular place, like @branchHit or @cInclude (RIP).
It also perfectly describe what it is (a generic parameter), and let the programmer use the right name for the parameter. For example auto: @Generic(), anyval: @Generic(), if that’s the actual meaning of it.
1 Like
I agree. I also think that @Generic() or @Infer() may be more appropriate.
A potentially inappropriate idea:
Allow @Generic(T)(or @Infer(T)) to accept a parameter, specifically an identifier, which is used to store the type of actual incoming value. In other words, value: @Generic(T), where T is an inferred type determined by the position of the function call, which also conforms to explicit philosophy and result position semantics.
For example:
fn func(value: @Generic(T)) void {
...
}
equivalent to
fn func(value: anytype) void {
const T = @TypeOf(value);
...
}
Even more radical ideas: use value: infer T, infer is a keyword, T is an identifier which is used to store the type of actual incoming value:
fn func(value: infer T) void {
...
}
6 Likes
I agree. Actually that’s my one wish.
It could even work for destructuring generics, like []infer T and such. And for making a function take the type of its result location fn () infer T.
5 Likes
Huh, how is this ‘News’? This is old (like 6 years old) and you linked a Github issue that is stale. Is there any work on this being done currently? Or is this a meme post?
The proposal is old, but it was only accepted ~9 hours ago.
2 Likes
I really thought this was a joke. What value does the rename bring?
5 Likes
Consistency, it’s laid out in the proposal. It’s a little easier to understand when you keep in mind that a type of some value can be a type (the type of types). As anyerror is a global set of all the error sets, you would expect anytype to be a global set of all the variants of type (which type actually is). But that is not case because it can be anything (any value) i.e. you can pass concrete instances of a type (e.g., 1, 4, 5, etc.) to a function instead of just the types themselves (e.g., i8). It’s actually a global set of all the values. So, anyval is a more natural fit (and I like that they went with the shorter version).
It may seem pedantic, but <1.0 is when they should be proactive about correctly aligning this type of stuff. Especially if they want to have a language spec one day.
I was never bothered with anytype either, but it’s an understandable change.
5 Likes
I’d actually like anyerr to be consistent with anyval now, since I like the more terse variants. 
But let me take this a step – or two – further!
anyvalue : anyv :: anyerror : anye
anyv : av :: anye : ae
4 Likes