Align nested enum value ordering with VSS `default` (proto3 zero-default semantics)

[aki1770-del]

Follow-up to discussion in #502 (review by @erikbosch).

In #502 we generate proto3 nested enums for string fields with allowed values, ordered by allowed list position. Proto3 assigns the first enum value to 0, which is also the implicit value when the field is unset on the wire.

VSS supports default on allowed-value fields. When a default is specified, the proto-default (enum 0 when field unset) does not currently carry that semantic — the enum ordering follows allowed order, not the default value.

Proposal

When a string field has both allowed and default:

• Sort the allowed list with the default value first
• Generated nested enum then has default at value 0
• Proto-default (unset field) aligns with VSS-default semantically

Out of scope of #502

#502 ships the basic generation. This issue tracks the semantic-alignment refinement as a separate change.

References

• VSS default usage example (cited by @erikbosch): https://github.com/COVESA/vehicle_signal_specification/blob/b6e55988161ca67b20a3cdc3bdc1953c2faae4df/spec/Powertrain/CombustionEngine.vspec#L50
• Originating discussion: feat(protobuf): generate nested enum for string fields with allowed values #502 (review thread)
• Proto3 default-value semantics: https://protobuf.dev/programming-guides/proto3/#default

AI-assisted — authored with Claude, reviewed by Komada.

[erikbosch]

MoM:

• Please discuss

[erikbosch]

My protobuf knowledge is somewhat limited, but I think the semantic definition of default value in VSS and Protobuf may differ somewhat. In VSS it indicates that the signal will have a value from start.I.e. without default there will be no value from start. The value could be anything allowed by the datatype. Protobuf has an "optional" flag, but AFAIK no way to set a custom default value for e.g. strings or integers.
For enums/allowed, I think it would be a reasonable limitation that if default is used it must match the first entry. If we would accept that we would not need to reshuffle the order, which might be confusing.

[aki1770-del]

You're right — I was conflating two different concepts. VSS default is an explicit initial-value assertion; proto3's "zero default" is what the wire returns when a field is unset, with no mechanism to set a non-zero default for strings or ints. Collapsing them by reshuffling allowed would overload one with the semantics of the other.

Your proposal is cleaner: if default is present alongside allowed, require default == allowed[0] rather than reordering. The canonical VSS pattern (allowed: ['UNKNOWN', ...] + default: 'UNKNOWN') already satisfies this, so no existing spec needs to change — only specs that set default to a non-first allowed value would fail validation, and that divergence was probably unintentional anyway.

I'll close this issue as the reshuffling proposal is withdrawn, and open a narrower one covering: (a) validate default ∈ allowed if both are set, (b) validate default == allowed[0] if both are set and the field generates a nested enum, (c) clear error messages pointing to the VSS pattern.