Union semantics and variant enumeration order for tag bits

[johanpel]

Currently, the spec says:

https://abs-tudelft.github.io/tydi/specification/logical.html#union-semantics

The "tag" field is used to represent which variant is being represented, by means of a zero-based index encoded as an unsigned binary number.

Do we want to allow custom tag enumeration of union variants? If yes, we should add this to the spec. If no, we should make explicit that the current text refers to the field index in the union declaration. In the example, the tag enumeration is done by order of variant appearance in the union declaration, which seems most logical and straightforward, and it is similar to what most programming languages do as far as I am aware.

[mbrobbel]

I'm against adding support for custom tag values for union variants to the spec without a motivation. We can always add this later as a non-breaking change by adding tag arguments to the variant types of a union type, that default to the index of the variant in the declaration.

I do see how this could be valuable for example when consuming streams of non-Tydi union types where the discriminants are encoded using a different pattern. However, users would still be able to match their type definitions by inserting Null types for unused tag values in the non-Tydi union type. This is also something that is easy to generate. For example, allowing users to annotate their types with attributes (e.g. bitfield tag encoding):

#[repr(bitfield)]
type Foo = union {
  a: Bits(4),
  b: Bits(3)
}

We can generate the logical type: Union<Bits<4>,Null,Bits<3>>.

Or allow users to explicitly pick tag values:

#[repr(Bits<3>)]
type Foo = union {
  a: Bits(4) = 3,
  b: Bits(3) = 1
}

We can generate: Union<Null, Bits<3>, Null, Bits<4>, Null, Null>.