Invalid type passed!
Received:
{type}
Expected one of:
{asideVariants.join(", ")}
: <>
{title &&
{title}
}
{children}
}
;
};
Experienced developers coming from FunC tend to ask questions like:
* *"What's the analogue of XXX in TL-B?"*
* *"How to generate a TL-B schema for a Tolk structure?"*
* etc.
Such questions lead in the wrong direction — because the Tolk **type system** is designed as a **replacement for TL-B**.
## Stop thinking in TL-B terms
Why is TL-B so widely used in TON today?
**Because contracts written in FunC are not declarative.**
They are low-level imperative programs that manually parse cells and slices.
TL-B exists to compensate for this — to provide a declarative description:
* which inputs are valid,
* which shape is expected,
* how storage is structured, etc.
**In Tolk, messages and storage are described directly in structs.**
This description *is exactly what TL-B used to provide* — but serialized automatically.
Moreover, **TL-B and the Tolk type system are not equivalent**, even if they look similar at first glance.
Similarities include:
* `intN`, `uintN`, `bitsN`
* `Maybe` (nullable), `Either` (a two-component union)
* multiple constructors (declared structs + prefixes + unions)
* cells and typed cells
But the differences are essential.
TL-B supports the following (not expressible in Tolk):
* `~tilde`
* `{conditions}`
* dynamic `## n`
Tolk supports the following (not expressible in TL-B):
* type aliases
* enums
* inline unions (auto-generated prefix trees)
* tensors
* custom `packToBuilder` and `unpackFromSlice`
* `address?` as "internal or none" (not "maybe T")
* further language improvements, such as namespaces or modules
The conclusion is simple: **all the tooling around Tolk will not involve TL-B**.
TL-B is excellent for describing blockchain internals like `block.tlb` — but not for contracts APIs or interaction models.