🫧 Tolk v0.11: type aliases, union types, and pattern matching

This update might confuse you at first. You may wonder: "Why do we need this? How will it be useful?". But in the end, you'll see how everything comes together bringing seamless and generalized message handling.

✅ Notable changes in Tolk v0.11:

1. Type aliases type NewName = <existing type>
2. Union types T1 | T2 | ...
3. Pattern matching for types
4. Operators is and !is
5. Pattern matching for expressions
6. Semicolon for the last statement in a block can be omitted

PR on GitHub with detailed info.

✔ Type aliases

Tolk now supports type aliases, similar to TypeScript and Rust.

type UserId = int32;
type MaybeOwnerHash = bytes32?;

An alias creates a new name for an existing type but remains interchangeable with it. No performance overhead — a compile-time feature.

✔ Union types `T1 | T2 | ...`

They now allow a variable to hold multiple possible types.

fun whatFor(a: bits8 | bits256): slice | UserId { ... }

var result = whatFor(...);  // slice | UserId

Nullable types T? are now formally T | null.

At the TVM level, union types work as tagged unions — similar to Rust enums but more flexible.

✔ Pattern matching

The only way to work with union types is matching them:

match (result) {
    slice  => { /* result is slice here  */ }
    UserId => { /* result is UserId here */ }
}

Matching is based on smart casts — inside each branch, the variable is automatically narrowed to the matched type.
 
It can also be used as an expression:

type Pair2 = (int, int);
type Pair3 = (int, int, int);

fun getLast(tensor: Pair2 | Pair3) {
    return match (tensor) {
        Pair2 => tensor.1,
        Pair3 => tensor.2,
    }
}

So, `match` + smart casts are our way for union types. You may notice that it's close to enums in Rust. But we don't have enum. Union types are more general and powerful.

✔ `match` for expressions

val nextValue = match (curValue) {
    1 => 0,
    0 => 1,
    else => -1
};

As you see, match also works for constant expressions, similar to switch in other languages.

✔ Union types and TL/B `Either`

T1 | T2 will be directly mapped to TL-B (Either T1 T2).
Look how clean this is: (Either SmallPayload LargePayload) becomes

struct StoragePart {
    data: SmallPayload | LargePayload;
    // (de)serialized as '0' + ... or '1' + ...
}

match (s.data) {
    SmallPayload => ...
    LargePayload => ...
}

No need to manually handle bits from the slice — it's naturally expressed in the type system!

✔ Union types and TL/B constructors

T1 | T2 | ... is a typed way to describe multiple constructors from TL/B. Generally, they can be used anywhere inside a storage or a message.

Moreover — handling incoming messages is beautifully expressed with union types.

✔ Union types and future structures

The ultimate goal? You'll describe each incoming message as a struct, create a union type for them, parse a slice, and just match over variants:

// don't mind about opcodes yet
struct CounterIncBy { byValue: int32 }
struct CounterReset {}
struct ... other messages

type IncomingMessage = CounterIncBy | CounterReset | ...;

// ... after parsing a message
match (msg) {
    CounterIncBy => {
        newCounter = curCounter + msg.byValue
    }
    CounterReset => {
        newCounter = 0
    }
    ...
}

🌳 So, union types (that perfectly work with tensors) will seamlessly work with structures. With union types, you will declare both Either and different kinds of messages. Combined with intN and other types, they will allow to express (almost) any practical TL/B construction. They are not limited to message routing — in other words, message routing does not differ from handling any field, any storage, or any cell in general.