Undefined, optional properties, and nullable unions are common TypeScript habits. Musi uses someOf and noneOf so expected absence has one visible shape in examples.
function findGate(ticket: string): number | undefined {
return ticket === "A12" ? 4 : undefined;
}let option := import "@std/option";
let findGate (ticket : String) : option.Option[Int] :=
match ticket (
| "A12" => option.someOf[Int](4)
| _ => option.noneOf[Int]()
);
findGate("A12");Reading Null, Undefined, Option, and Result from JavaScript/TypeScript
On the Musi side, Musi uses option.someOf and option.noneOf when absence is expected, so callers handle the empty branch deliberately. Read the shared example through JavaScript/TypeScript eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.
False friend
Do not translate null, nil, None, or undefined as a quiet ordinary value. For a TypeScript reader, the trap is assuming runtime object shape and compile-time behavior contract are the same thing; Musi class is not a JS constructor or TS class; it is a behavior contract implemented separately from record/data shape.
When this pays off
Use Option when a badge, ticket, receipt, search result, or lookup may honestly be missing. The JavaScript/TypeScript instinct still helps here: Keep the TypeScript habit of reading the shape before reading implementation details.