Explicit default values for enums:

[MichaelK-Bertrandt]

Add support explicit default values when decoding enums so you can then reference those later on in your structures.

In the below example in 'MyStruct.type' would decode to the known values, or if an unknown value is encountered (e.g. 3) it will decode to MyEnum.UNKNOWN. Using this information and the size it can either decode MyChoice or skip over it by putting a blob in its place.

enum uint8 MyEnum
{
UNKNOWN = 255,

FOO = 0,
BAR = 1
}

choice MyChoice on MyEnum
{
case FOO: int32 intValue;
case BAR: string stringValue;
}

struct MyStruct {
MyEnum type: default MyEnum.UNKNOWN;
uint32 bitSize;

MyChoice(type) knownValue: if type != MyEnum.UNKNOWN;
bit<bitSize> unknownValue: if type == MyEnum.KNOWN;
}

[fklebert]

Is this trying to address the same issue like #514? Namely creating enums and choices that are forward compatible?

I think we need to solve a couple of problems here:

1. Single usage of an enum value: This can probably be solved with the default in the generated code being a predefined _unknown value. That would put exception handling in the hands of the user code. You may then decide yourself whether you want to ignore the value or whatsoever. I think this is one part #514 addresses. The more challenging thing is...
2. Usage of an enum within a choice Here we have the issue that we need to skip over content that we do not know in V1 (as it had been defined in V2). So basically we would need a field for bitsize of the choice content in front of the actual payload. In case we hit _unknown() in the enum we could then skip the number of bits in the choice. This will have a massive size impact in case we are using choices in lists and the payloads of the choice's case are relatively small (like any base type).

[MichaelK-Bertrandt]

Yes it is the same core issue.

The 2nd point is a hard nut.

There are some special cases where you could do it with little to no size gain. e.g.

• if you have a list with the same choice value and static sized types could store their size in a header structure.
• if you have indexed offsets, you could use the offsets to calculate the individual size but you'd need a way find the size for the last element.