Idea: use undefined in place of anytype

Brainstorming
1

What do you think about using undefined in place of anytype?
It mirrors the use of undefined when assigning a value:

// not assigning a value right now, will be determined later.
// also implies that the value of foo can change.
// (Not really, but undefined constants are useless)
var foo: usize = undefined;

const Bar = struct {
    // not assigning a type right now, will be determined later.
    // also implies that the type of foo can change.
    foo: undefined;
};

// not assigning a type right now, will be determined later.
// also implies that the type of foo can change (between function calls).
fn bar(foo: undefined) void {}

Maybe not the most immediately intuitive way, but seems pretty logically consistent to me.
anytype is not a real type, but just a placeholder for one.
undefined is not a real value, but just a placeholder for one.
Seeing as zig is already treating types as values at least at comptime, why not unify the two?
Also saves on a keyword.

Relevant discussions:

2

Currently, undefined in Zig is also a type that can be coerced into any type.

We can find that undefined is one of the kinds of types in std.builtin.Type.

I’m not opposed to your suggestion, it’s just that this might conflict somewhat with the current undefined mechanism, and adopting it would require some other changes.

I originally replied to you in another post, but then I found that you deleted that reply and added a new topic. I tried to delete my reply and move it here, but ran into some trouble with similar replies. Well, so I added some nonsense to avoid being considered a similar reply.

3

Oh, I didn’t realize that undefined was an actual type. Thank you for the info.
undefined and anytype seem to be implemented very differently, but I still think they are quite close conceptually, aside from operating on different levels.

4

It’s not that undefined is an actual type. But it coerces into one (as it does into anything). Having a type that’s undefined until the call site is different than having a type that’s undefined at all.

1 Like
5

I think infer T or @Infer(T) may be more appropriate semantically.

See Replace `anytype` with `infer T`

6

I agree. But if you’re going to go for semantics, I think generic T is better suited.

7

I don’t think undefined should be special-cased like this. The current comptime rules are that whenever an attempt at reading undefined is made, the compilation fails. Replacing anytype with undefined would make this inconsistent.

Moreover, you can have functions that return a type. What would happen if such a function returned undefined?

fn MyType(a: u32) type {
	_ = a;
	return undefined;
}

fn doSomething(x: MyType(3)) void {
	// ... something ...
}

Would this make doSomething generic? What if you needed a var T: type = undefined; for later population in MyType’s logic?

I believe this idea solves nothing and only creates more problems, honestly.

2 Likes
8

I personally don’t like the overload of undefined because it kind of leads to the static keyword situation in C where static as a storage qualifier means it’s actually stored in the data segment, in front of a function it means it’s only visible within the file. inside of a function meaning it’s in the data segment with value persisting between calls.

I don’t like anytype, I don’t like anyval even less than anytype which is saying a lot, I think infer is the best name, because fundamentally anytype is a comptime placeholder to generate an instance of a function for which the argument type is inferred based on the call site usage.

anytype makes me think of something being type erased, anyval doesn’t really makes me think of anything.

Also even from a pure logical standpoint, qualifying that a value is of type anyval or anyvalue is so profoundly meaningless. Like a 5 is a value, “oiefjwioefjwoifj” is a value. but they both have a type one is a comptime_int the other is a *const [16:0]u8 fundamentally they have a type, and i don’t see how qualifying the type of something as being anyval makes any sense at atll

6 Likes
9

I am not strongly married to any of the proposed keyword/builtin replacements ( anytype never bother me as a keyword in the language), and I will get used to whatever they change it to without complaint.

That said, for the love of God, why is it anyval and not anyvalue?!
That seems borderline like an April Fool’s joke to me. Why break its consistency with other similar-named language constructs for the sake of 2 characters?

4 Likes
10

Ugh the bike shedding on this one is endless.

Why not “any” like python, and ts. That covers any type and any value. And is shorter.

2 Likes
11

Darn it, let’s just use an underscore:

fn bar(foo: _) void {}
6 Likes