Generics & concepts

Generic parameters

Sn uses angle-bracket parameter lists for generic types and functions. Value parameters use const N: Type.

Concepts

Concepts express compile-time structural requirements. Generic constraints use where T: Concept clauses. The intended model checks a generic body before materializing reachable concrete instances.

Static by default

Concepts do not introduce runtime identity, vtables, witness dictionaries, or reflection lookup. Dynamic dispatch is reserved for explicit virtual or interface call boundaries.

Bounded resolution

The design excludes speculative candidate search, SFINAE, and argument-dependent lookup. Only documented requirement forms are admitted; arbitrary compile-time predicates are not automatically supported.

Practical use

Inspect the public signatures of Vector, iterators, and allocator APIs for concrete generic requirements. Availability and exact constraint spellings depend on the selected documentation and toolchain version.

Example: require an operation, not a base class

pub concept Readable<Self> {
    requires readonly fn Read() -> i32;
}

pub fn ReadValue<T>(Value: readonly T&) -> i32
    where T: Readable
{
    return Value.Read();
}

The constraint states the operation the generic body needs. A matching type supplies Read; it does not need to inherit from a runtime interface just to meet this structural requirement. This uses the same requires readonly fn form as the standard allocator and indexing concepts.

Real library example: choose an allocator

pub final class Vector<T, A = DefaultAllocator>
    where T: Movable
    where A: Allocator, Defaultable, Movable
{
    // Container implementation.
}

This is a shortened public declaration from the standard library. The element's move requirement and the allocator's required operations are part of the API, rather than assumptions hidden in the implementation. See [Vector](/reference/dev/std-collections-vector/) for its complete declaration and worked example.