A C++ reader brings habits from RAII, overload sets, templates, references, optional values, exceptions, and object hierarchies. That helps with ownership stories, value categories, and compile-time abstractions, but the Musi page asks a narrower question: what contract should this branching and block results example make visible?
auto delivery_fee(int distance_km) -> int {
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 C++17
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 C++17 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 turning every Musi value into a class-shaped design; Musi class is closer to a concept or trait than a C++ class; records/data store shape, instances satisfy behavior.
When this pays off
Use this shape when a route fee, access decision, or small rule table chooses one value from several cases. The C++17 instinct still helps here: Keep the C++ habit of asking which operation is generic and which value owns shape.