when multiple union fields share a body in a switch prong, use a peer result type cast, rather than requiring identical types

[andrewrk]

Followup from #1107.

This test passes now:

test "switch prongs with cases with identical payload types" {
 const Union = union(enum) {
 A: usize,
 B: isize,
 C: usize,
 };
 const S = struct {
 fn doTheTest() void {
 doTheSwitch1(Union{ .A = 8 });
 doTheSwitch2(Union{ .B = -8 });
 }
 fn doTheSwitch1(u: Union) void {
 switch (u) {
 .A, .C => |e| {
 expect(@typeOf(e) == usize);
 expect(e == 8);
 },
 .B => |e| @panic("fail"),
 }
 }
 fn doTheSwitch2(u: Union) void {
 switch (u) {
 .A, .C => |e| @panic("fail"),
 .B => |e| {
 expect(@typeOf(e) == isize);
 expect(e == -8);
 },
 }
 }
 };
 S.doTheTest();
 comptime S.doTheTest();
}

But this diff:

- A: usize,
+ A: u8,
 B: isize,
- C: usize,
+ C: u16,

Gives this error:

/home/andy/downloads/zig/build/test.zig:18:28: error: capture group with incompatible types
 .A, .C => |e| {
 ^
/home/andy/downloads/zig/build/test.zig:18:17: note: type 'u8' here
 .A, .C => |e| {
 ^
/home/andy/downloads/zig/build/test.zig:18:21: note: type 'u16' here
 .A, .C => |e| {
 ^

However, I propose this should work. peer type resolution would make the type of e be u16 and everything is fine. Likewise a T could be grouped with a ?T.

[fengb]

How about explicitly typing the coercion to prevent accidental rogue casts?

.A, .C => |e: u16|

[andrewrk]

Can you give an example of an accidental rogue cast?

[fengb]

I'm afraid of situations where changing the field type should trigger an error. Example:

const Union = union(enum) {
 .A: u8,
 .B: u8,
// .C: u8,
 .C: u16,
 .D: u16,
};

In the current proposal, any switches that previously had A+B+C will automatically be "upgraded" to u16 without any warning. I'm not sure if this is an actual problem in practice, but I feel a little safer if it was opt-in.

[andrewrk]

I don't think this is an example of a rogue cast, so far everything is fine in this example.

[ifreund]

I don't like this as it is not obvious that coercion is happening and there is no language-level way to annotate the type of the capture. I'd much rather see #7224 accepted which would remove the need for this if I understand correctly while bringing considerable other benefits.

[SpexGuy]

I think those are separate use cases. #7224 requires separate code gen for each case, which could cause unnecessary code bloat. Especially on embedded platforms, the variant in this issue is preferred. The rules of coercion are designed so that it should not cause problems. I haven't seen any examples brought forth where the coercion would cause unintended issues, and I can't think of any.