Skip to main content
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.