# Capabilities are the effect system

Oska has no effect annotations (`! {Net}`). A function's effects are exactly the capabilities it can reach through its capability-bearing parameters. These include:
- explicitly marked `cap` types
- `cap fn` closures

Nondeterminism also comes from capabilities (`Clock`, `Random`). That means a function with no capability-bearing parameters is pure and deterministic.

We chose one mechanism instead of two. Finding 5 of the research recommends declaring effects in signatures, and capability parameters already do that. A separate effect system would duplicate the same information, and the two could drift apart.

There are two deliberate exceptions:
- `dbg(...)`, which is a compile error in release builds
- panics, which stop the task but have no effect on the outside world and cannot be caught

## Capabilities in type arguments

Whether a type carries a capability is decided from the type as fully written out. `List<Stdout>` and `Box<Stdout>` are capability-bearing because `Stdout` appears in them. Neither `List` nor a user-defined `struct Box<T>` needs a `cap` declaration. `cap` is required only when a type's own fields name a capability directly.

The capability is still visible on the page, in the type the signature spells out. Requiring `cap` on generic containers would have been wrong for `List<Int>`, `Option<Int>`, and every other container of plain data.