In most languages, if checks a boolean. Exceptions are thrown and caught. Separate mechanisms.

In Verse, everything is an expression that either succeeds (produces a value) or fails (produces nothing)

No booleans for control flow. x < 10 is failable — it succeeds if true, fails if false

Failable expressions run inside failure contexts (like if blocks)

When something fails, all side effects are rolled back automatically — speculative execution

# Failable array access: no index-out-of-bounds errors!
if (Element := MyArray[Index]):
    Log(Element)           # Only runs if Index was valid
else:
    Log("Index invalid")   # Failure path

# Chained failable operations with automatic rollback
var Gold : int = 100
var Inventory : []item = array{}

PurchaseItem(Item : item, Cost : int)<transacts><decides> : void =
    set Gold -= Cost          # Tentatively deduct gold
    Gold >= 0                 # Failable: fails if gold went negative
    set Inventory += array{Item}  # Add item

# If Gold >= 0 fails, the Gold deduction is rolled back!
            

Failure propagates naturally through expressions, and mutations within failure contexts are rolled back automatically.

# The <decides> effect marks functions that can fail
GetRarityMultiplier(Rarity : string)<decides> : float =
    if (Rarity = "Common"):    return 1.0
    if (Rarity = "Rare"):      return 1.5
    if (Rarity = "Legendary"): return 3.0
    false?   # Explicit failure: unknown rarity

# The <transacts> effect enables automatic rollback
Transfer(From : account, To : account, Amount : int)<transacts><decides> : void =
    set From.Balance -= Amount
    From.Balance >= 0    # Fails (and rolls back) if insufficient
    set To.Balance += Amount
            

The effect system tells you at a glance: this function might fail, and this function does speculative mutation.

<no_rollback> marks operations with irreversible side effects:

SendEmail(To : string, Body : string)<no_rollback> : void = ...
LaunchMissile()<no_rollback> : void = ...
            

Transfer(From : account, To : account, Amount : int)<transacts><decides> : void =
    set From.Balance -= Amount
    SendEmail(To.Owner, "Transfer received!")  # COMPILE ERROR!
    From.Balance >= 0                          # might fail and roll back
    set To.Balance += Amount                   # ...but the email is already sent
              

Same idea as Flix’s effect exclusion — the type system statically prevents mixing incompatible effects.

x := SlowOk()     # takes 10 units, succeeds
y := FastFail()   # takes 1 unit, FAILS
z := Use(x, y)    # needs both x and y
            

Lazy pulls from one end. Lenient pushes from all unblocked fronts simultaneously — and can abandon expensive work early.

In Verse, a type is a failable function. Applying int to a value succeeds if it’s an integer, fails otherwise.

# Type checking is function application:
if (N := int[SomeValue]):
    DoSomethingWith(N)     # N is known to be an int

# So you can define your own types the same way:
PositiveInt(X : int)<decides> : int =
    X > 0    # failable
    X

EvenInt(X : int)<decides> : int =
    Mod[X, 2] = 0
    X
            

Type checking, pattern matching, and validation are the same operation: apply a failable function.

Counting adjacent mines in a grid — the entire nested iteration, filtering, and counting is a single for expression:

for:
    Y->CellRow : Cells
    X->Cell : CellRow
    AdjacentX := X-1..X+1
    AdjacentY := Y-1..Y+1
    AdjacentCell := Cells[AdjacentY][AdjacentX]
    Cell <> AdjacentCell
    AdjacentCell.Mined?
do:
    set Cell.AdjacentMines += 1
            

Each line is a constraint. Failing lines (out-of-bounds access, self-comparison, non-mined cell) are silently skipped — not errors.

This is quantification over a solution space, not nested loops with bounds checking.