comptime struct fields

[andrewrk]

const std = @import("std");

const Foo = struct {
    a: i32,
    comptime b: i32 = 1234,
};

test "example" {
    var foo: Foo = undefined;
    comptime std.debug.assert(foo.b == 1234);
}

A comptime struct field requires a default initialization value. Loads from a comptime struct field result in a comptime value of the default initialization value. Stores to a comptime struct field assert that the stored value is the default initialization value.

Generally, one should use a global const instead of a comptime field. The reason for using a comptime field is when you want reflection over struct fields to find the data as a field. For example:

const std = @import("std");

fn dump(args: var) void {
    inline for (std.meta.fields(@typeOf(args))) |field| {
        std.debug.warn("{} = {}\n", field.name, @field(args, field.name));
    }
}

pub fn main() void {
    dump(.{
        .int = 1234,
        .float = 12.34,
        .b = true,
        .s = "hi",
        .T = [*]f32,
    });
}

This will construct an anonymous struct with all comptime fields and pass it to dump. Each iteration in the for loop will evaluate the @field(...) expression and produce a comptime value.

This is a prerequisite to #208 which is already accepted.

[andrewrk]

See #208 (comment) for @Hejsil's alternate proposal for how to solve this problem.

[marler8997]

This is a good read:

https://guide.elm-lang.org/appendix/types_as_sets.html

When you view types as "sets of values", it's true that any type that only has 1 possible value does not require any memory to represent. In Zig:

const Foo = enum {A};

the Foo type takes 0 bits to represent. However, enums are only integer values. Providing the ability to create new fundamental types could have some benefits. For example, the type set that has no values could be used as a return type to represent a function that does not return. If we assume @Never() represents this type with no values, then this function would never return:

fn func() @Never() { ... }

Making full use of the type system can result in less additions to the language making things simpler overall.

Knowing these things, the onePossibleValue mechanism sounds promising to solve this issue.

[marler8997]

By the way, here's an implementation of oneValueType with current zig:

fn OneValueType(comptime value: var) type {
    const TheEnum = enum { OneValue };
    return union(TheEnum) {
        OneValue: @typeOf(value),
    };
}

However, this doesn't work since any argument you pass to OneValueType will have a type with many possible values.

[marler8997]

And another way you could define the @Never() type would be with an empty enum. This function would never return:

fn foo() enum {} {...}

[JesseRMeyer]

Is there a reason why 'comptime' is used to qualify b instead of 'const'? I feel I'm missing a nuance here. Consider that Default Field Values are implicitly comp-time known, and this proposal seems to add constness semantics on-top of DFVs.

[Rocknest]

I don't understand why a new type or field type is needed. I think it would be better to have

try @comptimeLoad(struct, name);

Is it possible?