A C reader brings habits from headers, translation units, pointers, arrays, errno, sentinel returns, and small functions that trust callers. That helps with cost, layout, and the exact boundary where bytes cross into code, but the Musi page asks a narrower question: what contract should this named cases and pattern matching example make visible?
enum TrafficLight { RED, YELLOW, GREEN };
int can_walk(enum TrafficLight light) {
return light == GREEN;
}let TrafficLight := data {
| Red
| Yellow
| Green
};
let canWalk (light : TrafficLight) : Bool :=
match light (
| .Green => 0 = 0
| _ => 0 = 1
);Reading Enums, Variants, and Patterns from C99
On the Musi side, Musi data variants name the cases directly, and match reads the case split at the point where the answer is chosen. Read the shared example through C99 eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.
False friend
Do not keep integer tags, string unions, subclass checks, or table marker fields when a data variant is the real shape. For a C reader, the trap is treating convention as a contract; Musi class is not a C struct with function pointers; records/data carry shape, classes name behavior a type can provide.
When this pays off
Use data variants when an order, animal, traffic light, payment state, or parser result has a closed set of cases. The C99 instinct still helps here: Keep the C habit of asking where memory, symbols, and failures come from.