Proposal: make comptime fields immutable (for realsies)

[mlugg]

Tuples and structs in Zig support comptime fields, which are effectively declarations with a fancy hat on. These fields have a fixed value which is associated with the type itself.

A slightly weird thing about comptime fields is that they're actually semantically considered mutable: the catch is that the value you store to them must be comptime-known to match the current value. For instance:

const S = struct {
    comptime a: [2]u32 = .{ 123, 456 },
};
test "store to comptime field" {
    var s: S = .{};
    s.a[0] = 123; // this is fine
    s.a = .{ 123, 456 }; // this is fine
    s.a[0] = 600; // this emits an error
}

foo.zig:8:12: error: value stored in comptime field does not match the default value of the field
    s.a[0] = 600; // this emits an error
    ~~~~~~~^~~~~

Because pointers to comptime fields are semantically considered mutable, they unfortunately have the same restrictions as pointers to comptime vars, introduced in #19414. This limits the usefulness of these fields, and can be particularly frustrating since fields of untyped anonymous initializations are implicitly made comptime.

However, there does not appear to be any reason these fields have to be mutable. I would guess that the main reason is for RLS-style initialization: in the example above, perhaps we want s = .{ .a = .{ 123, 456 } } to be valid. I think this makes sense, because of the fact that if no type were given, you would get a type with a comptime field; it would be strange if explicit specification of the struct removed the ability to initialize its comptime field. Thus, I do not propose disallowing comptime fields from appearing in struct iniitalization expressions, although the field initializer must -- like today -- be comptime-known and match the field value. I do, however, propose that "normal" pointers to such fields should always be considered immutable. They should have a const pointer type, and attempting to mutate through them at comptime should raise a compile error. This would remove the restrictions in place on these fields, allowing them to be referenced at runtime just like non-comptime fields. I believe this change would improve "perceived simplicity" of the language, i.e. how difficult it is to learn/understand (and the impact on actual spec simplicity should be fairly neural).

[Lking03x]

You are right the language should not accept that but it's not for RLS to work.

Zig struct "field" themselves have NO reason to be const/comptime AFAIK. For the use of static member declarations associated/namespaced with a struct type one do this:

const S = struct {
    // "const" or "var" as a normal variable declaration
    const a = expr;
    var b = expr2;
};

Both a and b are associated as static members, have a type which can be inferred, and their expression can be comptime.
a is immutable, b is not.

[silversquirl]

@Lking03x comptime fields are an important and useful feature. Decls do not cover their usecases.

For example, they allow writer.print("{} {}\n", .{runtime_value, 7}) to inline the 7 because it's comptime-known, while still allowing runtime_value to be handled at runtime.

[ethernetsellout]

Would this entail rejecting #5675?

[mlugg]

#5675 is a proposal which offers a completely different form of "comptime field" that exists today. This proposal, on the other hand, is a simple augmentation of the current feature.

Thus, acceptance and implementation of this proposal need not directly lead to rejection of #5675; it could still be accepted in future and overrule this behavior. (I should, however, note that I am like 95% confident that proposal will be rejected.)

[vadim-za]

FWIW, just ran into this issue. Here's the minimal reduction from the real use case:

pub fn func(ptr: anytype, some_runtime_arg: i32) void {
    _ = ptr;
    _ = some_runtime_arg;
}

pub fn main() void {
    var literal = .{ .field = 1 };
    func(&literal.field, 0); // fails to compile
}

[npc1054657282]

@vadim-za

untyped anonymous initializations are implicitly made comptime

Maybe this is the reason.

[vadim-za]

@vadim-za

untyped anonymous initializations are implicitly made comptime

Maybe this is the reason.

Yes, it seems to be the reason. That's why I put my comment under this issue.
It was pretty weird having my code working as long as the field is initialized to a runtime value and producing a compile error otherwise. Took a while + a forum discussion to figure out.

Edit: if anybody cares about the real use case. I wanted to use anonymous struct literals to pass a number of optional named anytype arguments into a function. The function would simply check the presence of fields with known names, and if a field is present, it would react to the field contents. Sometimes I need to take pointers to these fields (e.g. if a field needs to be passed around to a nested function call). Maybe those can be passed by values, but I'm hesitant to do that, as PRO is currently under re-consideration. Also I'm not sure it's 100% about PRO, I think I had situations where I simply needed a field pointer.

[vadim-za]

Maybe the following example is rather illustrative:

fn f(_: anytype) void {}

pub fn main() void {
    // This constant is comptime-known
    const t: i32 = 1;
    // And I can pass its address to f()
    f(&t);

    var i: i32 = 0;
    _ = &i;
    const tuple_literal = .{ i, t };
    const struct_literal = .{
        .i = i,
        .t = t,
    };

    // But I cannot do this to comptime-known
    // literal fields
    f(&tuple_literal[1]);
    f(&struct_literal.t);
}

This (in a more complicated situation) has been driving me nuts. First to figure out, what's going on, and then looking for workarounds.