default untagged union field type to void

[emekoi]

when no type is specified for a untagged union field, default to void as it's type.

[andrewrk]

Can you share some reasoning behind this proposal, and some code examples to illustrate?

[emekoi]

the following generates an error:

const Foo = union {
    A: u8,
    B: f32,
    C
}; 
pub fn main() void {
    var f = Foo { .A = 2 };
    @import("std").debug.warn("{}\n", f.A);
}

because Foo.C doesn't have an explicit type. however the following does work:

const Foo = union(enum) {
    A: u8,
    B: f32,
    C
}; 
pub fn main() void {
    var f = Foo { .A = 2 };
    @import("std").debug.warn("{}\n", f.A);
}

as far as i can tell the only reason for this is this line.

[andrewrk]

So the idea is to be consistent with a tagged union, is that correct?

For some history, the reason that tagged unions allow you to leave off the type is that they serve as a mix between a union and an enum. When you have a tagged union with all void field types, that's equivalent to an enum. However for untagged unions, there is no tag, and so in your example the field C doesn't really exist - there is no tag, no payload for it. It seems strange.

[emekoi]

consistency is the idea, but i was also wondering if there is a reason that this would be incompatible with packed or extern unions?

[rohlem]

I don't think there is anything in the way of implementing this feature, it's more of a question why you would want the code to be legal.

With tagged unions, the compiler will take the field into consideration when generating the corresponding enum, you can set C to be the active field and check for that.
With untagged unions, any access would necessarily result in a no-op. You cannot check for the active field - the only way to observe the difference would be querying the union's members via reflection.

As I understand it, explicitly specifying void, as might happen in generic code, is supported. Leaving out the type means you deliberately put a useless field into your untagged union.
I don't have a strong stance on the decision either way, but to me it seems disallowing this pattern might prevent a typing mistake - for example relying on the error behaviour via the hidden generated tag in debug builds, when you actually meant to make the union tagged. With no thinkable use case (it seems to me), I think the status-quo error is justified.

[andrewrk]

I agree with @rohlem's reasoning.