Skip to content

The tour

Each page of the tour covers one idea: what it looks like, why it works that way, and the part of the specification that defines it. You can read them in any order.

Errors as values

!-> on a signature marks a function that can fail, and one or clause handles the failure. The same clause handles an optional and a null pointer. An unhandled failure is a compile error. Errors →

RAII in three members

A constructor, drop and copy. The compiler writes moves and assignments, a moved-from value is reset to its defaults, and the compiler chooses where memory comes from. Ownership →

Safety without a borrow checker

A program with no unsafe has no undefined behaviour on one thread. kills clauses catch a reference a call invalidated, arithmetic is defined, and aliasing stays legal. Safety →

Modules without headers

One manifest per module says what every file can name. There are no headers, no include order and no per-file import lists, and declaration order never matters. Modules →

C and C++ from source

A short recipe builds the library, and libclang turns its header into a Dazzle module, with classes and overloaded methods included. C++ interop →

Macros the editor understands

Macros are declarative and hygienic, and their expansions are written in Dazzle. The editor still completes and hovers inside an invocation. Macros →

Generics checked where they are written

Bounds are checked at the definition, then Dazzle monomorphizes. Traits dispatch statically or through a fat pointer, and unions switch exhaustively. Types and generics →

A standard library in Dazzle

List, a SwissTable HashMap, SlotMap, a String that keeps short text in place, vectors and matrices, files, time and random numbers, none of them taking an allocator. Standard library →

Tooling from day one

There is a language server and a VS Code extension, plus dz fmt, dz fix and dz explain. Tests and benchmarks are written beside the code they cover. Tooling →