#0.4. #[lang] slot mapping table

The #[lang(slot_name)] attribute (refs-lang 6.4) registers a standard library item in a slot that the compiler can look up. This chapter collects in one place, in tabular form, every slot name, its meaning, and the item it is attached to.

The slot table is the authoritative location in the spec; the compiler, the standard library and users all refer to it to stay consistent. If slot names drift, the contract between the language and the library breaks down, so any change starts from this table.

#0.4.1. Slot classification

The 48 slots fall into four groups according to their responsibility. The table below shows the role and slot count of each group at a glance, indicating which category the detailed tables in the following sections belong to.

#0.4.2. Type slots (14)

Type slots indicate the concrete type the compiler lowers to when it encounters a literal or keyword. This group divides further into two kinds. First, there are the language default types exposed directly as lowercase identifiers. They need no separate keyword registration and are the primitives users encounter every day.

Language defaults (lowercase struct, no #[keyword] needed):

Second, there are the PascalCase types additionally provided by the standard library. These expose a familiar lowercase alias to users separately via #[keyword(...)]; items directly entangled with language syntax gather here, such as the auto-promoting int and float, the none sentinel, and the Range literal.

Standard library additions (PascalCase struct + #[keyword(...)]):

A compiler that provides the primitive types built in may leave i32_type ... str_type, none_type and char_type unattached.

#0.4.3. Trait slots (30)

Trait slots indicate which trait the compiler goes to when user-written syntax is desugared into a standard library trait call. Core syntax such as for loops, indexing, slicing, formatting and await all resolves through the traits registered here, so this table is the thickest bridge between the language syntax and the library.

Next come the operator trait slots. The dispatch target of an operator token is determined by the #[infix] / #[prefix] (refs-lang 6.7) attached to each trait method, and precedence is fixed by the table in refs-lang 3.2; the slots below are fixed locations that let the compiler find "the addition trait", "the comparison trait", etc. by name during primitive lowering and diagnostics. Compound assignment (AddAssign, etc., 2.4), broadcast (DotAdd, etc., 2.6) and floored modulo (Modulo, %%) traits need only #[infix] registration and have no slots.

#0.4.4. Function slots (3)

Function slots are for standard library functions that the compiler calls directly, like intrinsics. They mainly cover abnormal termination paths - throw, OOM, unreachable - and are used where a uniform entry point is needed outside normal flow.

#0.4.5. Method slots (1)

Method slots are for methods the compiler calls automatically without the user writing the call. There is only one: disposal when a using binding is released. The ? operator is expanded directly by the compiler for T | none (refs-lang 3.14.10), so it has no method slot. Cloning a value (Clone::clone) is never called automatically (2.13.2), so it is registered as the trait slot clone_trait, not a method slot.

#0.4.6. Slot consumers: where the compiler looks up slots

Where the previous sections listed "which slots exist", this section summarizes the reverse: "when the compiler looks up which slot". When tracing which standard library item a line of user syntax resolves to, the following table is the starting point.

#0.4.7. Duplicate / missing detection

If two standard library items are attached to the same slot, the compiler rejects it (the duplicate detection rule of refs-lang 6.4.6). Conversely, if a required slot such as iterator_trait is missing, compilation of the features that depend on it - here, for loops - is rejected. Both are devices that force the slot contract to have a single source of truth.

The actual attached items are stated in each chapter of 200-core/. Every slot in this table has its #[lang(...)] attachment site in the chapter indicated by the "Ref" column. A slot name not in this table is a compile error per refs-lang 6.4.8 - for example, Stream has no slot (2.8.10).

#0.4.8. Slot naming policy

Finally, the naming rules to follow when adding a new slot or renaming an existing one. Consistent names let the kind of a slot be guessed just by scanning the table, so the policy is not taken lightly.

Names are written in snake_case: type slots take the _type suffix, trait slots the _trait suffix, function slots the _fn suffix, and method slots the _method suffix (drop_method). A slot designating a whole trait is unified under a single _trait even if the compiler handles several methods or derives of that trait; method slots are limited to cases where the compiler automatically calls one specific method. By this criterion, Clone is registered as clone_trait, not clone_method. The suffix also determines the attachment site: a _trait slot is attached to the trait declaration itself, a _method slot to the corresponding method inside the trait, a _type slot to a type declaration, and a _fn slot to a function declaration; attaching it elsewhere is rejected by the signature check of refs-lang 6.4.7.

Edit this page on GitHub