eliminate anytype fields from the language

[andrewrk]

Motivation

Simplify the language. Most people probably aren't even aware that this is possible:

const S = struct {
    x: anytype,
};

Similarly, the simplified language will be simpler to implement compilers for. Such as, you know, the one that is the main focus of the 0.10.0 milestone.

Proposed changes

Mainly, make it a compile error to use anytype as a field name. However this poses some problems to solve, such as how to deal with @typeInfo for various things. For example, the sentinel field of pointers:

https://github.com/ziglang/zig/blob/0.9.0/lib/std/builtin.zig#L239-L252

Likewise the sentinel field of arrays, the default_value field of structs, and the function field of async frames. But that's it. I can't find any other dependencies on this feature in the entire standard library.

In order to address this problem, this proposal suggests to use compile-time type erasure by using ?*const anyopaque instead of anytype. This is something that the language is already required to support, so we are exploiting it here rather than introducing yet another way of doing the same thing via anytype struct fields.

--- a/lib/std/builtin.zig
+++ b/lib/std/builtin.zig
@@ -222,11 +222,10 @@ pub const TypeInfo = union(enum) {
         child: type,
         is_allowzero: bool,
 
-        /// This field is an optional type.
         /// The type of the sentinel is the element type of the pointer, which is
         /// the value of the `child` field in this struct. However there is no way
-        /// to refer to that type here, so we use `anytype`.
-        sentinel: anytype,
+        /// to refer to that type here, so we use pointer to anyopaque.
+        sentinel: ?*const anyopaque,
 
         /// This data structure is used by the Zig language code generation and
         /// therefore must be kept in sync with the compiler implementation.
@@ -244,11 +243,10 @@ pub const TypeInfo = union(enum) {
         len: comptime_int,
         child: type,
 
-        /// This field is an optional type.
         /// The type of the sentinel is the element type of the array, which is
         /// the value of the `child` field in this struct. However there is no way
-        /// to refer to that type here, so we use `anytype`.
-        sentinel: anytype,
+        /// to refer to that type here, so we use a pointer to anyopaque.
+        sentinel: ?*const anyopaque,
     };
 
     /// This data structure is used by the Zig language code generation and
@@ -264,7 +262,7 @@ pub const TypeInfo = union(enum) {
     pub const StructField = struct {
         name: []const u8,
         field_type: type,
-        default_value: anytype,
+        default_value: ?*const anyopaque,
         is_comptime: bool,
         alignment: comptime_int,
     };
@@ -364,7 +362,7 @@ pub const TypeInfo = union(enum) {
     /// This data structure is used by the Zig language code generation and
     /// therefore must be kept in sync with the compiler implementation.
     pub const Frame = struct {
-        function: anytype,
+        function: ?*const anyopaque,
     };
 
     /// This data structure is used by the Zig language code generation and

Example of printing the default value for the first field of a struct:

const S = struct {
    x: i32 = 1234,
};

test "example" {
    const field = @typeInfo(S).Struct.fields[0];
    const default_value = @ptrCast(*const field.type, field.default_value.?).*;
    @compileLog(default_value);
}

Example of constructing an array type:

test "example" {
    const Array = @Type(.{ .Array = .{
        .len = 10,
        .child = i32,
        .sentinel = &@as(i32, 1234),
    });
    @compileLog(Array);
}

Related Issues:

• anytype fields cannot be initiated to array or struct literals #5877
• Nit: anytype is a really inconsistent name #5893
• @typeName fails on TypeInfo.StructField.field_type if the struct field is declared as anytype #7740
• Proposal: Make anytype a full (comptime-only) type #9107
• Proposal: A new formulation of anytype-based generics #9272

[Hejsil]

There is also the question of how to generate types with sentinel and default fields values using @Type

[andrewrk]

There is also the question of how to generate types with sentinel and default fields values using @Type

Ah right, thank you. Amended.

[marler8997]

The @Type construct feels simpler to me than creating builtins for specific use cases. It's the inverse of @typeInfo and feels natural to have both. I agree it's "clunky" but that seems like it could be solved with helper functions in std.meta rather than language builtins. Otherwise, if we considered the reverse, would it be simpler to have a @ptrInfo @intInfo rather than one @typeInfo?

[InKryption]

Maybe the current rendition of @Type is overreaching; is there a use case for being able to retify void, noreturn, undefined and null? Maybe each class of type should have its own retification builtin, which would make this a fair bit more consistent, and remove these unnecessary edge cases.

Edit: Thinking about it further, is there even a need for being able to retify opaque types with a builtin? The only significant information about an opaque type is its declarations, which can't actually be retified (and afaik isn't planned to be possible?). If you want to generate a unique opaque type with no declarations, you can just write opaque {}.

[andrewrk]

If you read this proposal before this comment, read it again because I changed everything (except for the main goal of eliminating anytype fields from the language).

[andrewrk]

is there even a need for being able to retify opaque types with a builtin?

no, there is not. opaque{} is the preferred way to create a new opaque type. Many uses of @Type are redundant:

• @Type(.Void) should be avoided in favor of void
• @Type(.Type) should be avoided in favor of type
• @Type(.Bool) should be avoided in favor of bool
• @Type(.NoReturn) should be avoided in favor of noreturn.
• @Type(.ComptimeFloat) should be avoided in favor of comptime_float
• @Type(.ComptimeInt) should be avoided in favor of comptime_int
• @Type(.Undefined) is equivalent to @TypeOf(undefined) and it is unclear which is preferred, and that is a problem.
• @Type(.Null) is equivalent to @TypeOf(null) and it is unclear which is preferred, and that is a problem.
• @Type(.EnumLiteral) is equivalent to @TypeOf(.foo) and I guess the @Type one is slightly better.
• @Type( .{ .Optional = .{ .child = T } }) should be avoided in favor of ?T.
• @Type( .{ .ErrorUnion = .{ .error_set = E, .payload = T } }) should be avoided in favor of E!T.
• @Type(.BoundFn) should be avoided
• @Type(.{ .Vector = .{ .len = len, .child = T }}) sucks, @Vector(len, child) is way better. and please don't suggest to reach into std.meta to use basic primitive types of the language.

[daurnimator]

• @Type(.Void) should be avoided in favor of void

Would that also be equivalent to @TypeOf(void)? or even @TypeOf({})?

[InKryption]

@daurnimator

• @Type(.Void) should be avoided in favor of void

Would that also be equivalent to @TypeOf(void)? or even @TypeOf({})?

@TypeOf(void) is type.

[ikskuh]

Using ?*const anyopaque, is a way better and less hacky solution than using a anytype field. I really like this change, especially as it makes clear if we have an optional initialized to null or no default value:

.{ .name = "a", .type = ?u32, .default_value = null },
.{ .name = "b", .type = ?u32, .default_value = &@as(?u32, null) },

[Hejsil]

Getting the default value needs an @alignCast as well, right?

const default_value = @ptrCast(*const field.type, @alignCast(@alignOf(field.type), field.default_value.?)).*;

Could probably use a helper method for doing this :)