Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

How to define item types

Type definitions describe item types with named, typed fields. Fields have types, defaults, and mutability (definition or instance).

Duplicate type registration fails

If you attempt to register a type with a name that already exists in the registry, the operation will fail with a duplicate type error. For example, after registering a “sword” type, trying to register another type also called “sword” — even with different field defaults — will be rejected. Each type name must be unique within the registry.

Look up unregistered type fails

If you look up a type that hasn’t been registered — such as “nonexistent” — the registry returns a not-found result rather than crashing or returning a default. This lets you safely check whether a type exists before trying to use it.

Register a type with fields

When you register a new type in an empty type registry, you define it with a name and a set of typed fields. For example, registering a “sword” type with four fields — a string “name” defaulting to “Sword”, an f32 “damage” defaulting to 10.0, an i32 “width” defaulting to 1, and an i32 “height” defaulting to 3, all with definition-level mutability — adds that type to the registry with all four fields intact.

Register a type with instance-mutable fields

When you register a type in the registry, each field can be marked as either definition-mutable or instance-mutable. For example, registering an “armor” type with a “name” field (string, default “Armor”, definition mutability) and a “durability” field (i32, default 100, instance mutability) means that “durability” can be changed on individual item instances, while “name” is fixed at the type definition level and cannot be modified per-instance.


Generated from core/tests/features/type_registry.feature