typst/typst · error
cannot mutate fields on {ty}
Error message
cannot mutate fields on {ty} What it means
From access_dict in the evaluator: a field-mutating operation (like `obj.field = x` or `obj.field += y`) targeted a value whose type is one of symbol/content/module/function/args — types that expose read-only named fields via their own getters rather than a mutable dictionary. The at-fault input is the target value of such a type.
Source
Thrown at crates/typst-eval/src/access.rs:93
pub(crate) fn access_dict<'a>(
vm: &'a mut Vm,
access: ast::FieldAccess,
) -> SourceResult<&'a mut Dict> {
match access.target().access(vm)? {
Value::Dict(dict) => Ok(dict),
value => {
let ty = value.ty();
let span = access.target().span();
if matches!(
value, // those types have their own field getters
Value::Symbol(_)
| Value::Content(_)
| Value::Module(_)
| Value::Func(_)
| Value::Args(_)
) {
bail!(span, "cannot mutate fields on {ty}");
} else if typst_library::foundations::fields_on(ty).is_empty() {
bail!(span, "{ty} does not have accessible fields");
} else {
// type supports static fields, which don't yet have
// setters
Err(eco_format!("fields on {ty} are not yet mutable"))
.hint(eco_format!(
"try creating a new {ty} with the updated field value instead"
))
.at(span)
}
}
}
}
View on GitHub (pinned to 35417aa769)
Solutions
- Mutate a dictionary instead of these read-only field types
- Wrap the data in your own dictionary and mutate that
- Rebuild the value (e.g. with a show rule or constructor) instead of mutating its fields
Defensive patterns
Strategy: type-guard
When it happens
Trigger: Thrown at crates/typst-eval/src/access.rs:93 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of typst/typst@35417aa769 (2026-08-17).
Data as JSON: /api/errors/5472e6288c66ca10.
Report an issue: GitHub.