A C# reader brings habits from nullable flow analysis, records, LINQ, async tasks, extension methods, interfaces, namespaces, and attributes. That helps with domain code through named APIs and tooling feedback, but the Musi page asks a narrower question: what contract should this native and unsafe boundaries example make visible?
[DllImport("clock")]
private static extern int clock_ms();
static int NativeClockMs() => clock_ms();foreign "c" (
let clock_ms () : Int;
);
export let nativeClockMs () : Int := unsafe {
clock_ms();
};Reading Unsafe, Interop, and FFI from C#
On the Musi side, Musi foreign declarations use foreign "c" let ... or a parenthesized foreign group, and unsafe calls stay inside unsafe { ... }. Read the shared example through C# eyes: keep the useful instinct, then let Musi name shape, behavior, absence, and outside work in separate places.
False friend
Do not invent a C-like foreign block or spread unsafe assumptions through ordinary Musi code. For a C# reader, the trap is mapping Musi classes to object classes or service containers; Musi class is a typeclass-style behavior contract, not a CLR class with fields, constructors, and inheritance.
When this pays off
Use this shape when a clock, driver, C library, host VM, or platform handle must cross into Musi. The C# instinct still helps here: Keep the C# habit of making api shape readable at the call site.