Reference
How types work
Swift reads your code before it runs it, and it refuses to run code that can’t make sense — a number that might be nil, a whole number added to a decimal, a switch that forgets a case. That’s the compiler catching bugs early. Here are the ideas the lab drills. Open the compile lab →
- A type error is the compiler on your side
The red error isn’t the compiler being difficult — it caught a bug BEFORE the code ran. Every error you fix at compile time is a crash a user never sees.
- An optional might be nil — so you must handle it
An `Int?` is a number OR nil. Swift won’t let you use it as if it’s always there. Unwrap it with `if let`, force it with `!` (only when you’re sure), or give a default with `??`.
- Swift won’t silently mix a whole number and a decimal
`let a = 3` makes an `Int`; `let b = 0.5` makes a `Double`. `a + b` won’t compile — Swift never converts a named value for you. Ask for it: `Double(a) + b`.
- A let never changes; a var can
`let` means "this value is fixed". Reassigning it is a compile error. If something must change, use `var`.
- A switch must cover every case
A `switch` over an enum must handle every case (or add a `default`). The compiler makes sure you never forget one — including the case you add to the enum next year.
- Read the fix, not just the change
Many changes make code compile. Only some keep it doing what it was meant to do — a catch-all `default` compiles, but it can quietly give the wrong answer. The right fix does both.
Compile errors you’ll meet — and the fix
- must be unwrapped
You used an optional (`Int?`) directly. Unwrap it first: `if let`, `!`, or `??`.
- can't mix Int and Double
One side is a whole number, the other a decimal. Make them match.
- 'let' constant can't change
You reassigned a `let`. Use `var` if it needs to change.
- switch must be exhaustive
A case is missing. Add it (or a `default:` for the ones you don’t list).
- cannot find in scope
A name was used before it was made — a typo, or a `let`/`var` you forgot.
The programs are original teaching examples in a teaching subset of the Swift language — enough to meet the type system that catches these bugs. Nothing you read leaves your device. Read a program →
Before this: TraceForge (run a program in your head before you change its types). The twelve Syntax Bridge programs are the same in all three: built in SyntaxForge, read in TraceForge, and here handed to the compiler, sometimes with the tempting wrong token.
Where this idea comes from
The lost orbiter
On 23 September 1999 NASA’s Mars Climate Orbiter fell too deep into Mars’s atmosphere and was lost. One team’s ground software reported the thruster pushes in pound-force seconds; the navigation software that read them expected newton-seconds. Every number was off by a factor of about 4.45, and for months no check caught it.
One thing to hold: A thruster log: a column of numbers with no unit written next to them.
Why it matters: Both programs were passing plain numbers, so nothing could tell the two units apart. A type that carries the unit (a Force in newtons, not just a Double) lets the compiler refuse to mix them, the same way Swift refuses to add an Int and a Double without being asked.
What we don’t know: The investigation found the unit mix-up was the cause, but also that the people who noticed odd numbers had no process that made anyone stop and check. A type system catches one kind of mistake, not all of them.
Dates:
- 1998 Mars Climate Orbiter launches.
- 1999 It is lost on arrival at Mars, on 23 September.
- 1999 The investigation board names the unit mix-up, on 10 November.