Read the API reference

The complete package directory lists every source package shipped with Dodo. Each package page contains its public types, fields, enum variants, constants, functions, and methods, with exact signatures and links to their implementation. These pages are generated when the documentation is built, so new declarations appear automatically.

Use the standard-library guide to choose an API and learn its behavior. Use this reference when you need an exact name or parameter type. The guides explain contracts that a signature cannot express: capacity limits, partial writes, invalidation, numerical accuracy, and operating-system support.

Find a declaration

Open the package directory, expand a package family in the sidebar, or search with Ctrl+K (Cmd+K on macOS). Search accepts names such as split_at_mut, Buffer.reserve, or std/encoding/json. A type’s methods appear below its declaration. Public fields and enum alternatives are shown inside the type declaration; private storage and method bodies are omitted.

Start with these frequently used packages:

Read a signature

Consider this declaration from core/slice:

pub fn get<T>(data: &[T], index: usize) -> Option<&T> from(data)

Read it from left to right:

1. pub makes the function accessible outside its package.
2. get<T> works with an element type T, often inferred from data.
3. data: &[T] borrows a read-only slice; it does not take ownership of the array.
4. index: usize accepts a pointer-sized unsigned index.
5. Option<&T> returns either some(reference) or none for an absent element.
6. from(data) ties the returned reference to the input’s storage. The reference cannot outlive that storage or overlap a conflicting write.

A complete use looks like this:

package lookup
import "core/slice"

fn main() {
    values := [10i32, 20, 30]
    match slice.get(&values, 1) {
        some(value) => { assert_eq(*value, 20) },
        none => { assert(false, "index 1 should exist") },
    }
}

Save it as lookup.dodo and run dodo run lookup.dodo. It exits successfully without printing. The * reads the integer behind the reference.

Recognize the common types

usize is commonly used for lengths, indices, and capacities. Its width follows the compilation target. Numeric as conversions use the language’s range checks; integer narrowing does not truncate or wrap. Unsafe raw-pointer casts do not validate the pointed-to storage or extend its lifetime.

See types and functions, ownership, and Results and options for the language rules behind these signatures.

Receivers and constructors

Methods are declared inside their struct. The first parameter determines how a call uses the receiver:

A new function is an ordinary named function, not special syntax. It may return a value directly, an Option, or a Result. Check its return type before adding ! or ?. A new name does not imply a hidden heap allocation.

Returned views often borrow the receiver. Finish using those views before calling a method that mutates, grows, clears, moves, or destroys their owner. The container guide explains additional restrictions for reference-bearing elements.

Errors, unsafe calls, and compiler-expanded functions

For T!E, use match to recover, ? in a function with a compatible Result return type to propagate, or postfix ! to unwrap success and panic on error. Read the guide’s failure contract before retrying: I/O can fail after a prefix was transferred, and failed insertion can consume its input.

An unsafe fn needs an unsafe call context. Its source comments and guide define obligations such as initialization, alignment, aliasing, and allocator validity. Merely obtaining a raw pointer is different from dereferencing one. See memory and foreign calls.

Some declarations use @compiler(print), @compiler(println), or @compiler(printf). The compiler expands these calls. In particular, printf accepts a literal format followed by heterogeneous arguments even though its source declaration only names the format parameter. The formatting guide documents accepted values and format syntax. These attributes identify bundled compiler hooks; they are not general user extension points.

Compiler intrinsics

The following functionality lives in the compiler, so it has no .dodo source package for the generator to extract. It remains part of the documented API:

Import core/mem, core/ptr, or core/mmio before using its short package name. core.drop, wrapping arithmetic, and assertions need no import. Prefer safe library abstractions over the storage intrinsics they use internally.

Virtual imports and target providers

Imports ending in /native select the implementation for the target. Some are virtual package names rather than independent source files:

std/net/native is the socket entry point; many other native packages implement the higher-level facade shown in their guide. Explicit /linux and /windows pages document provider boundaries. Their presence in the index does not mean both can be used on every target. C runtime support files are implementation dependencies, not importable Dodo packages.

Versions and source links

These pages describe the source checkout used to build this website. The library is embedded in each compiler binary. A released dodo can therefore expose fewer methods than the latest documentation on main; check dodo --version and the release notes.

The generator preserves source spellings, including a few accepted historical type-first fields. Application examples use current canonical syntax. Source links point to main and show the declaration’s line in the documentation build; line numbers can shift after later commits. For a reproducible comparison, inspect the same file at the tag or commit used to build your compiler.