The assignability rules for unions require matching or the member_id. By default these are assigned sequentially so a union that just reorders the cases becomes incompatible.
This seems overly restrictive.
For non-mutable unions, the value of the memberId is never serialized so there is no reason it should influence the type assignability. Considering it just makes unions brittle without providing any extra safely as this is already provided by the discriminator value.
For mutable unions we are serializing the memberId ahead of the member. However, when it comes to deserializing the member that will hold the value is can be selected by the value of the discriminator. We could also use the memberId since it is available, but it is unclear what benefit that would carry.
The current union assignability rules for assigning T1 from T2 require that members with the same ID has the same name and members with the same name have the same ID. However they do not require that the members selected in T1 and T2 for a give value of the discriminator have the same ID or name. They just need to be assignable.
For example the unions T1 and T2 are assignable:
union T1 switch (int32) {
case 1:
@id(10) int32 x;
case 2:
@id(20) int64 y;
};
union T2 switch (int32) {
case 1:
@id(30) int32 xx;
case 2:
@id(40) int64 yy;
};
However the unions T3 and T4 are not assignable
union T3 switch (int32) {
case 1:
int32 x;
case 2:
int64 y;
};
union T4 switch (int32) {
case 1:
int32 xx;
case 2:
int64 yy;
};
In addition, if the union has a default case with a member specified it becomes impossible to add new cases because the default case has a single memberId which cannot match the memberId of multiple future cases.
For example
union U1 switch (int32) {
case 1:
@id(10) int32 x;
default:
@id(20) int64 y;
};
union U2 switch (int32) {
case 1:
@id(10) int32 x;
case 2:
@id(30) int64 x2;
default:
@id(20) int64 y;
};
Union U2 added a new case, since it is not a explicit case in U1 it would end up in the default branch, but there is no way for it to match the specific memberId in the default branch. This means we cannot take advantage 'default' negating the whole point of this construct...
Given this, it seems like considering the memberId as part of assignability makes the union brittle and harder to extend. Without providing additional protection. Specially given that by default member IDs are assigned sequentially.
Changing serialization rules for mutable unions would break existing systems. So it seems we should keep serializing the member ID. However we could relax compatibility rules to make unions easier to extend.
(1) For final/appendable unions. we could just remove the condition on member ID. They would just be ignored as well as member names. As long the member selected by the discriminator has assignable types it would be enough.
Alternatively, If we want additional protection, we could we could require that any non-default member selected in T1 has the same name as the member selected in T2. We could also say that if the members do not have the same name, then we check the ID and if the ID matches then we allow it. This would allow changing names as long as the ID is kept the same. But the benefit is not so clear given IDs are assigned sequentially by default. So we might want to combine this with assigning IDs as HASH by default.
(2) For mutable unions, We could either ignore IDs and names (similar than final/appendable) or we could default to using @autoid("HASH")
(3) We should apply a different criteria to the default branch. There it should be enough that the types match, regardless of the name of the member or its ID.
As long as we change assignability rules to be more lenient it should not break existing systems s.