Anytype is getting renamed to anyval (!)

News
43

linking this here as it would be relevant.

9 Likes
45

Excited for advancements in this area, but the

// implement peer type resolution in userland 🤮🤮:puke emoji:

comment in the Clamp example feels ominous.

What would Writer.print’s signature even look like? Well, I can guess what the signature would look like, but I mean also the boilerplate to make it work inside the function’s body.

46

In that particular case, it would actually be simpler as const ArgsType = @TypeOf(args) could be removed, with args: anytype being replaced with args: |ArgsType|. That’d be the only change you’d need for it to work exactly as before.

In the case of std.math.clamp, he purposefully omitted that you could make it clamp(value: |T|, min: T, max: T) T, because that isn’t actually the same behaviour as clamp(value: anytype, min: anytype, max: anytype) @TypeOf(value, min, max).
The coercions are performed differently, because of the wholly unique property of anytype that I mentioned earlier.

Here’s a demonstration:

fn clamp(value: anytype, min: @TypeOf(value), max: @TypeOf(value)) @TypeOf(value) {
	return @min(max, @max(min, value));
}

test clamp {
	const value: u16 = 0xFFFF;
	const min: u8 = 0;
	const max: u32 = 0x2009;
	
	// std.math.clamp() coerces to the widest of the three types...
	comptime if(@TypeOf(std.math.clamp(value, min, max)) != u32) unreachable;
	// But clamp() always coerces to the FIRST type passed in.
	comptime if(@TypeOf(clamp(value, min, max)) != u16) unreachable;
}

THIS is what we would be losing.

3 Likes
47

I’m really liking it, syntactically it’s also correctly giving comptime vibes because it reminds me of using comptime T: type in function signatures. The clamp example is a bit iffy, it would be cool if they could work in something like @pierrelgol suggested here.

1 Like
48

The type slot doesn’t contain the type of the type, it’s the type of the values that have that type. Thus anyval/anyvalue/anything is appropriate in the type slot, as the values that have that type can be any value / anything, just as anyerror and anyframe are appropriate in the type slot for values that can be any error or any frame.

This was hashed out in the original discussion on the issue and conceptual confusions like yours were corrected / refuted … you would do well to read that discussion.

49

The OP is SpexGuy, who is the least likely person on the planet to be confused about Zig semantics. And contrary to a number of confused people here, his logic as laid out in the issue is quite correct.

50

It communicates that the argument is an unknown type, which is incorrect … rather it’s a value that has an unknown type. People here seem to have difficulty understanding the difference between being a type and having a type. Consider a value that might be any sort of number. Its type (in a language that has types like this, and many do) might be AnyNumber. It would not be AnyNumberType. The type of the value is any number type, but the name of that generic type is AnyNumber, not AnyNumberType. Generalizing this to values of all sorts, their generic type is AnyValue (or Anything), not AnyValueType or AnyType.

51

so if the value could be of any type, any error, any frame etc ….. so just “any” is the logical choice?

Also the creators of - C++, Swift, TypeScript, Rust, and Python all seemed to think “any” made since as a catch all. Not to say you jump off a bridge if your friend jumps but a lot of smart ppl work on those languages and I’m sure they thought about it too.

2 Likes
52

As much as I dont like to see all this renaming happening at this late stage, I could get behind generic. I like that it does what it says on the tin :slight_smile:

The ones I look forward to less are bitpack and real. I still think ff32 for fast-float would work better. For packed struct maybe just make the type mandatory and call it packed(u?) eg packed(u32).

But what I really dont like is the perceived ‘zero cost’ of these random renames, justified by ‘the tool does it for you’. It ignores the cost of having to relearn the new language syntax. Not to mention all the books, tutorials, examples etc that are rendered useless. The only positive is that it hopefully confuses the LLM crowd :wink:

53

The bitpack change is just a spelling change. It was a reasoned decision and not at all random. Zig doesn’t make random changes. There is no new syntax. It will clarify a huge confusion the new users coming from C/C++ regularly get hung up on. I welcome this one.

Zig is pre 1.0, so part of the deal is that things are changing, in both big and small ways. I’m impatient with the useless wailing when something changes. It’s what you signed up for. What changed and how to migrate are usually either automated or well documented.

3 Likes