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 native and unsafe boundaries example make visible?
extern "C" int clock_ms();
auto native_clock_ms() -> int { return clock_ms(); }foreign "c" (
let clock_ms () : Int;
);
export let nativeClockMs () : Int := unsafe {
clock_ms();
};Reading Unsafe, FFI, and Native Boundaries from C++17
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++17 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 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 clock, driver, C library, host VM, or platform handle must cross into Musi. The C++17 instinct still helps here: Keep the C++ habit of asking which operation is generic and which value owns shape.