#[repr(transparent)]pub struct DeclId(pub u128);Expand description
Identifies a type declaration, independent of type parameters.
Think of DeclId as a “type-parameter-erased” version of Shape::id. While
Vec<u32> and Vec<String> have different Shape::id values, they share
the same DeclId because they come from the same Vec<T> declaration.
§How DeclId is computed
§Non-generic types
For types without type parameters (like u32 or MyStruct), DeclId is
trivial—it can simply equal the hash of the type identifier. When implementing
Facet for such types, you don’t need to do anything special; if you don’t
call .decl_id() on the builder, it’s automatically computed from the
type_identifier.
§Generic types with #[derive(Facet)]
For generic types using the derive macro, DeclId is computed from:
file!():line!():column!()#kind#TypeNameFor example: src/lib.rs:42:1#struct#Wrapper
This strategy assumes no two declarations exist at the exact same source location. This isn’t strictly true with macros that generate multiple types, which is why we also include the type name. Even so, this can be defeated in edge cases—it’s a best-effort approach.
§Foreign generic types (manual Facet implementations)
When implementing Facet for an external generic type (like Vec, Arc,
HashMap), set the module_path on the builder:
ShapeBuilder::for_sized::<Arc<T>>("Arc")
.module_path("alloc::sync")
// ... other fields ...
.build()The DeclId is then auto-computed from: @{module_path}#{kind}#{type_identifier}
For example, Arc in alloc::sync with type struct produces:
@alloc::sync#struct#Arc
This is also not foolproof—if you have two different versions of the same
crate in your dependency graph, they’ll produce the same DeclId even though
they’re technically different declarations.
§Example
use facet::Facet;
#[derive(Facet)]
struct Wrapper<T> {
inner: T,
}
// Different types (different Shape::id)
assert!(<Wrapper<u32>>::SHAPE.id != <Wrapper<String>>::SHAPE.id);
// Same declaration (same Shape::decl_id)
assert!(<Wrapper<u32>>::SHAPE.decl_id == <Wrapper<String>>::SHAPE.decl_id);§Stability
DeclId is completely opaque and provides no stability guarantees:
- NOT stable across different compilations
- NOT stable across refactors (adding a comment changes line numbers)
- NOT stable across reformatting (column numbers change)
- NOT suitable for persistence or serialization
The only guarantee: within a single compilation, the same declaration
produces the same DeclId.
This is sufficient for runtime use cases like “group all instantiations of
Vec<T> in this program” but NOT for cross-compilation comparisons or
persistence.
Tuple Fields§
§0: u128