requires — Gateando Capacidades
Nesta página
requires declara uma dependência obrigatória do módulo. O compilador consulta
a tabela de capacidades do alvo ativo e, se qualquer cláusula falhar, aborta o
build com um diagnóstico claro apontando a diretiva — nenhum código chega a
rodar sem as capacidades necessárias.
Capacidades conhecidas incluem backend.{vm,native,wasm},
platform.{posix,linux,macos,windows}, feature.{fs,net,process,signals,threads, gpu,bigint} e version >= X.Y. Várias cláusulas podem ser empilhadas: todas
precisam ser satisfeitas.
A forma mais simples exige que o módulo rode apenas no backend VM, com acesso ao sistema de arquivos, e em uma versão mínima da linguagem:
Três requires em sequência; o compilador os valida antes de qualquer fn.
// Feature: `enable` and `requires` directives
// Syntax: `enable <feature>;` / `requires <capability>;`
// When to use: gate a module on backend capabilities (FS, signals,
// threads, GPU, ...) or platform (POSIX vs Windows). Build fails
// early with a clear message instead of panicking at runtime.
//
// See `specs/enable-requires-directives.md` for the full specification.
requires backend.vm
requires feature.fs
requires version >= 0.1
// `enable` activates optional language features. Unknown features emit
// a warning (forward-compat); enabling a feature unsupported on the
// current backend is a hard error.
//
// enable simd // available only on backend.native / .wasm
// enable signals // available on backend.vm / .native
//
// Diretivas devem aparecer no topo do arquivo, antes de `use`, `fn`,
// `struct`, etc. Diretiva após declaração → E_DirectiveNotAtTop.
fn main() {
print("directives validated at build time; nothing to do in runtime")
}
// Run:
// zolo run 01-enable-requires.zolo
// → directives validated at build time; nothing to do in runtime
//
// Try changing `requires backend.vm` to `requires backend.native` —
// the build will now fail with E_CapabilityMissing pointing at the
// directive, before any of your code runs.
Quando o módulo depende de múltiplas features em conjunto — por exemplo, fs e
process — cada uma ganha sua própria linha. Chegar na main já significa que
todas estão disponíveis, sem precisar de fallbacks em tempo de execução:
requires feature.fs + requires feature.process garantem ambas antes da execução.
// parity-sub: pid:\s*\d+ => pid: <N>
// Feature: gating a module on multiple capabilities + a minimum
// language version.
//
// `requires` can be stacked — every clause must hold or the build
// aborts with `error[D0002]`. Common gates:
// - `requires backend.{vm,native,wasm}`
// - `requires platform.{posix,linux,macos,windows,wasm}`
// - `requires feature.{fs,net,process,signals,threads,gpu,...}`
// - `requires version >= 0.1` // monotonic, never expires
//
// See specs/enable-requires-directives.md for the full capability table.
requires version >= 0.1
requires feature.fs
requires feature.process
use std::fs
use std::process
fn main() {
// Reaching this line guarantees fs + process are available on the
// active target — no runtime fallback needed.
print("pid: {process.pid()}")
let cwd_ok = fs.exists(".")
print("cwd writable: {cwd_ok}")
}
// Try editing the file to add `requires backend.wasm` — building for
// the VM target should now fail with a clear diagnostic instead of
// crashing at runtime.
Desafio
Adicione requires backend.wasm ao arquivo 02-platform-gating.zolo e tente
compilar para o alvo VM. O que aparece na mensagem de erro? Qual capability está
faltando?
Veja também