v4.3.0

Released 2026-05-27 · GitHub release · CHANGELOG

Brings back the @@import directive — removed in 4.2.0 — in a strictly narrower, analysis-only form, and fixes a composed-child persist-naming bug in both its same-file and cross-file forms. Sources that don’t use @@import generate byte-identical output to 4.2.x, so upgrading is safe by default.

Highlights

  • @@import "<path>" returns as an analysis-only directive (RFC-0040 — Re-introduce @@import as analysis-only cross-file resolution). framec reads the referenced Frame source while compiling the current file to resolve and check cross-file references, but emits nothing for it — no import line and no target code for the imported system. It changes what framec knows, never what it writes; native host imports remain your own pass-through. This deliberately keeps the emission removal from RFC-0024 while restoring the cross-file analysis that removal had also cost.
  • Composed-child persist names now resolve — same file (#44). When a parent composes a child (domain: child = @@Child()) and the child renamed its persist ops with @@[save(name)] / @@[load(name)], the parent’s save_state / restore_state called the child by the hardcoded target-default name — a runtime TypeError that was silent at compile time. The parent now calls the child’s declared names across all 14 persist backends.
  • …and across files. With @@import, that same resolution works when the child lives in another file: the parent reads the imported source and calls the child’s declared names instead of the default.
  • Imported @@[main] no longer trips E806 (#45). Importing a Frame source whose primary system carries @@[main] no longer fails the importer’s single-@@[main] check — that rule is correctly scoped to locally declared systems.

Cross-file argument/type validation (surfacing imported-call signature mismatches) is a planned RFC-0040 follow-up and does not fire yet — @@import currently resolves names and existence, not call shapes.