The enum approach is nice for matching keycodes, but it imposes practical limits on how the space can be subdivided. Enum variants are always split on the byte boundary, which means in 16 bits we can only have two levels of enums (one top level enum, where each variant can have one 8-bit field (either raw or an enum with unit variants)).
For reference, QMK doesn't use any compound types, just 16-bit values and some predicates and unpacking routines to figure out what each keycode is.
I'd like to keep the enum representation for more elegant matching, but making the keycode enum larger would be a problem, as it has a drastic effect on code size with the keymaps being stored in the program flash. So I'm considering a hybrid approach, keeping the rich type representation but also defining a "compressed" keycode format that fits in 16 bits so it can be used in storage, and providing methods to do the conversion between these two representations.
The enum approach is nice for matching keycodes, but it imposes practical limits on how the space can be subdivided. Enum variants are always split on the byte boundary, which means in 16 bits we can only have two levels of enums (one top level enum, where each variant can have one 8-bit field (either raw or an enum with unit variants)).
For reference, QMK doesn't use any compound types, just 16-bit values and some predicates and unpacking routines to figure out what each keycode is.
I'd like to keep the enum representation for more elegant matching, but making the keycode enum larger would be a problem, as it has a drastic effect on code size with the keymaps being stored in the program flash. So I'm considering a hybrid approach, keeping the rich type representation but also defining a "compressed" keycode format that fits in 16 bits so it can be used in storage, and providing methods to do the conversion between these two representations.