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 branching and block results example make visible?
int delivery_fee(int distance_km) {
if (distance_km == 0) {
return 0;
}
return 45;
}let deliveryFee (distanceKm : Int) : Int := match distanceKm (
| 0 => 0
| _ => 45
);
deliveryFee(3);Reading Blocks and Control Flow from C99
On the Musi side, Musi blocks and matches are expressions when they produce a value; the branch answer matters more than the statement container. 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 carry over temporary variables whose only job was to smuggle a branch result out of a statement block. 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 this shape when a route fee, access decision, or small rule table chooses one value from several cases. The C99 instinct still helps here: Keep the C habit of asking where memory, symbols, and failures come from.