What a function may do belongs in its type.

fn load_config() {
    read_file("ops.toml");        // reaches the filesystem
}

$ buildc check missing_effect.bld
function `load_config` performs effect `FileSystem` but does not declare it
  help: add ~ FileSystem to the signature
  note: capability `FileSystem` was triggered by ambient call(s): read_file

# declare the effect, and the same check passes, then writes a receipt
fn load_config() ~ FileSystem { read_file("ops.toml"); }

$ buildc check load_config.bld --receipt receipt.json
Type checking... OK
  "declared_effects":      { "load_config": ["FileSystem"] }
  "observed_capabilities": { "load_config": { "FileSystem": ["read_file"] } }

Touch your files without saying so, and it won’t build; the error points at the exact line that did it. Declare it instead, and it passes, and the compiler writes down what you promised, right next to what it actually saw you do.

Captured live from buildc check (Rust toolchain, release build) · the effect is built into the function and checked every time it’s called. That little receipt is the heart of it (what you promised, side by side with what really happened), and it’s honest that this is the foundation, not a finished, ship-it-tomorrow product.

fn pick<'a, 'b>(x: &'a i32, y: &'b i32) -> &'a i32 {
    y          // returns 'b where the signature promised 'a
}

$ buildc check pick.bld
Lexing... OK (28 tokens)
Parsing... OK (1 items)
Type errors found:
  function returns `&'b i32` but expected `&'a i32`

Here’s what’s happening: the function promised to hand back one specific piece of memory, then tried to hand back a different one that might disappear sooner. The compiler catches the swap and says no. How long memory is allowed to live is a promise too, and it’s kept.

Diagnostic from compiler/src/types/error.rs, surfaced through the lifetime matching in unify.rs. An honest limit, said plainly: this memory-lifetime checking is not yet complete. It already follows memory as it passes between functions (that’s the Phase 1 work), but I haven’t finished proving every case at the caller’s side, so I won’t claim it’s complete.

# an algebraic effect with a handler: parsed, effect-checked,
# lowered to C, compiled, and run:
$ buildc run examples/quickstart/effects_greeting.bld
Hello, teammate!

That same promise-keeping follows the program the whole way down: read it, check what it’s allowed to touch, translate it into the C language, and run it. From there, one path turns it into a real program your machine can run on its own.

The C path is the one that works start to finish, and the tests prove it. The others (LLVM, WASM, SPIR-V, x86-64, ARM64, and a route that writes Rust) can produce code, but they’re still experiments. I’d rather just tell you that than let you assume otherwise.

# name a C library by its header and link flag, then call straight in:
extern "C" link "sqlite3" header "<sqlite3.h>" {
    fn sqlite3_libversion() -> &str;      // the header stays authoritative
}
fn main() ~ Foreign { let v = sqlite3_libversion(); }

$ buildc build examples/ffi --emit c
[4/4] Code generation (c)... OK (53517 bytes)

# in the emitted C, verbatim:
#include <sqlite3.h>          // your header, included as-is
// buildc-link: sqlite3       // recorded, so `buildc build` links it
_1 = sqlite3_libversion();    // the real call into the C library

# the reverse is `extern "C" fn` (C calls BuildLang). and a live run
# straight through a C variadic:
$ buildc run examples/variadic/main.bld
the answer is 1 and 2

Name a C library by its header and link flag, and BuildLang includes the header, records the link, and calls straight in. extern "C" fn goes the other way, so C can call back. A foreign call is still an effect: main declares ~ Foreign, so reaching into C sits behind the same gate as touching a file.

Captured live from buildc build --emit c and buildc run (release build). buildc emits the include, the link directive, and the call, checked end to end through the build; the final native link against sqlite3 is your own C toolchain’s job, not something the test suite claims for you.