TypeScript.CodeCompared.To/Swift

Swift scripts run as top-level executable statements, exactly like a TypeScript file executed directly with tsx — no class Main or entry-point boilerplate. print appends a newline automatically, just as console.log does.

Swift interpolates inside ordinary double-quoted strings with \(expression) rather than TypeScript's backtick-delimited ${expression}. There is no separate template-literal syntax in Swift — any string literal supports interpolation.

This is the single most important trap for a TypeScript programmer: in TypeScript, let is mutable and const is fixed. In Swift, the meaning is reversed — let is the immutable, compiler-enforced binding, and var is the mutable one. Swift has no keyword that behaves like TypeScript's let.

The colon-suffixed annotation syntax is nearly identical between the two languages. The difference is underneath: TypeScript's string/number/boolean are erased before the program runs, while Swift's String/Int/Bool remain real, checked types in the compiled binary.

TypeScript has one runtime numeric type, a 64-bit float, so number covers integers and decimals alike. Swift distinguishes Int from Double as genuinely different types; mixing them requires an explicit conversion such as Double(wholeNumber), and the compiler rejects silent mixing.

Swift destructures tuples with parentheses, where TypeScript destructures arrays with brackets. Both languages can swap two variables without a temporary. Swift tuples can also carry named elements, for example let point = (x: 10, y: 20), accessed as point.x.

This is the deepest philosophical difference between the two languages. TypeScript's typing is structural — any object with a matching shape satisfies an interface, with no explicit declaration required. Swift's typing is nominal — a type must explicitly state : HasName to conform to a protocol, even if its shape already matches. A Swift type with the right members but no declared conformance simply does not satisfy the protocol.

TypeScript types are completely erased when the compiler emits JavaScript — value is Point style guards are hand-written checks the developer must maintain, and nothing prevents a mismatched object from being cast with as Point. Swift's types exist in the compiled binary and are enforced by the runtime, so is performs a genuine type check rather than a convention the programmer promises to uphold.

TypeScript's any turns off type checking entirely — a value typed any can be reassigned to any type and any member access compiles, even one that does not exist, deferring the failure to runtime. unknown is safer but still lets you widen freely with a cast. Swift has no equivalent escape hatch: Any can hold any value, but the compiler still requires an as?/as! cast, checked against the value's real runtime type, before any member can be accessed.

TypeScript has two absence values, undefined and null, which must be unioned onto a type explicitly (string | undefined). Swift has exactly one, nil, and wraps it into a genuine Optional<T> type (spelled T?) rather than a union. A non-optional String can never be nil — the compiler statically rules it out, whereas TypeScript's guarantee depends on strictNullChecks being enabled and honestly followed.

TypeScript narrows string | undefined to string with a plain if comparison, and the narrowing is a compiler analysis over the union — there is no separate binding step. Swift's if let actualName = name both tests for nil and introduces a new, non-optional binding scoped to the block, making the unwrap an explicit, visible step rather than an inferred narrowing.

Swift's guard let is the idiomatic early-exit unwrap: unlike if let, the unwrapped binding remains available for the rest of the enclosing scope after the guard statement, and the else branch is required to exit (return, throw, break, or continue). TypeScript's closest analogue is a plain early-return if check with no compiler-enforced exit requirement.

The ?? operator is spelled and behaves the same way in both languages: it evaluates to the right-hand side only when the left-hand side is nil/undefined/null. Swift's version is additionally checked so that the right-hand side must match the optional's wrapped type.

TypeScript borrowed ?. directly from languages like Swift, and the short-circuiting behavior is identical: if any link in the chain is absent, the whole expression evaluates to undefined/nil without throwing. In Swift, chaining through any optional automatically wraps the final result in an optional, which the compiler tracks precisely.

TypeScript's non-null assertion ! is purely a compile-time suppression of the type checker — it is erased entirely, so an incorrect assertion just silently produces undefined at runtime with no error at all. Swift's force-unwrap ! is a genuine runtime operation: if the optional is actually nil, the program traps and crashes immediately with a clear fatal error, rather than letting a wrong value quietly propagate.

Swift's string API favors descriptive method names — uppercased(), contains(_:) — and .count rather than .length. Swift's String counts extended grapheme clusters (what a human perceives as one character), which can differ from JavaScript's UTF-16 code-unit-based .length for text containing emoji or combining characters.

Swift uses triple double-quotes """ for multi-line strings, where TypeScript uses backtick template literals for the same purpose. The closing """'s indentation establishes the baseline that Swift strips from every line, which keeps multi-line strings readable inside indented code.

+ and += concatenate strings identically in both languages. In Swift, += requires the target to be declared with var; attempting it on a let constant is a compile error, unlike TypeScript where reassigning a let-bound string simply requires it not be const.

Swift arrays are homogeneous by default and use .count rather than .length. Swift provides .first and .last as optional-returning properties — a safer alternative to raw indexing, since an out-of-bounds Swift array index crashes at runtime with no graceful undefined the way a bad TypeScript index access would return.

Swift's mutation methods use descriptive names — append instead of push, insert(_:at:) instead of unshift — and every removal method returns the removed element directly. A Swift array declared with let is fully immutable; mutation requires var, which TypeScript arrays never enforce since const only prevents rebinding the variable, not mutating the array.

The names and semantics of map/filter/reduce carry over directly, but Swift spells closures with braces and in rather than TypeScript's arrow syntax. Swift's reduce(_:_:) takes the initial value as its first argument, where TypeScript's reduce takes it last.

A TypeScript Record<string, number> is really just an object typed as a fixed-key/value map, and reading a missing key silently returns undefined even when the index signature promises a number. Swift's [String: Int] dictionary makes every lookup return Int?, so the possibility of a missing key is visible in the type itself and must be handled, typically with ?? or optional binding.

Swift's for (key, value) in dictionary destructures pairs directly, with no equivalent of Object.entries() needed. Neither language guarantees iteration order for its map type (TypeScript objects only preserve insertion order for string keys as an implementation detail codified since ES2015, not a documented contract for arbitrary key types).

Swift if statements read almost identically to TypeScript's, but the parentheses around the condition are optional in Swift and conventionally omitted, while the braces are mandatory — there is no braceless single-statement if the way TypeScript allows.

Swift has no three-part for (init; condition; increment) loop; numeric iteration uses ranges instead — 0..<5 is a half-open range excluding 5, and 0...5 is a closed range including 5. Iterating a collection directly with for item in items is the same pattern as TypeScript's for...of.

Swift's switch never falls through by default — no break statements are needed, and omitting one in TypeScript is a common source of bugs that Swift structurally rules out (add the explicit fallthrough keyword if you actually want that behavior). Swift additionally requires every switch to be exhaustive, verified at compile time, where TypeScript only warns about unhandled cases when strict mode and careful typing line up.

Swift spells the run-at-least-once loop repeat { } while where TypeScript uses do { } while. Swift also removed ++ and -- entirely, in favor of += 1 and -= 1, to eliminate ambiguity between prefix and postfix forms.

Swift places the return type after -> rather than after a colon at the end of the parameter list, and every call site uses the parameter name as an argument label by default — greet(name: "World"), not greet("World"). A single-expression function body can omit return entirely.

Swift functions can declare a separate external label (used by callers) and internal name (used inside the body) for each parameter, producing call sites that read like a sentence: move(to: 10, and: 20, at: 5). TypeScript has no equivalent — a caller either relies on positional order or must adopt a conventional options-object parameter to achieve similar clarity.

Both languages have first-class closures that capture variables from the enclosing scope by reference. Swift wraps the closure body in braces with the parameter list and in keyword replacing the arrow; type inference often shortens this to { value in value * 2 }, and shorthand argument names ($0, $1) can eliminate parameter naming altogether.

When a closure is the last argument to a function, Swift lets it move outside the parentheses as a "trailing closure" — numbers.filter { ... } rather than numbers.filter({ ... }). TypeScript has no syntactic equivalent; an arrow function argument always stays inside the call's parentheses.

Default parameter values work the same way in both languages. Because Swift call sites use argument labels, skipping a default parameter is always unambiguous — the following argument is identified by name rather than by position, which avoids the "gap" problem TypeScript can hit with purely positional optional parameters.

JavaScript and TypeScript have exactly one kind of compound value: the object, always held and assigned by reference. A TypeScript programmer has no vocabulary for "copy on assignment" because nothing in the language ever behaves that way. Swift makes this an explicit choice per type, which is the subject of the next several concepts.

A Swift struct is a value type: assigning it, passing it to a function, or storing it in a collection always copies the value. TypeScript can only approximate this by remembering to spread ({ ...point1 }) at every assignment — a manual discipline, not a language guarantee — so forgetting a spread silently reintroduces aliasing. Structs are Swift's default choice for simple data, favored because independent copies eliminate a whole class of aliasing bugs.

Swift class instances behave exactly like TypeScript objects: assignment shares the same instance, and mutating through one reference is visible through all others. Swift uses access-control keywords (private, internal, public) instead of the # prefix TypeScript borrowed from the ECMAScript private-fields proposal, and instantiation calls the type name directly with no new keyword.

Both languages support single inheritance for classes, with a colon in Swift (Dog: Animal) replacing TypeScript's extends. Swift requires override on every overriding method — matching TypeScript's optional override modifier — but Swift additionally requires that inherited method calls be resolvable statically unless the base method is marked to allow it, keeping the inheritance model stricter overall.

A Swift struct gets a free memberwise initializer generated by the compiler — no constructor body needed for the common case, which is even terser than TypeScript's constructor(public name: string) parameter-property shorthand. Swift classes, by contrast, always require an explicit init, another practical reason structs are preferred for plain data.

This is a common surprise going the other direction: a TypeScript programmer's instinct is that assigning a collection to a new variable creates an alias, so mutating one mutates both. Swift arrays and dictionaries are value types that use copy-on-write internally for efficiency, but semantically they always behave as independent copies — mutating alias here never touches original.

A TypeScript interface is satisfied structurally — any value with a matching speak(): string method qualifies, even an inline object literal, with no declaration required. A Swift protocol must be explicitly adopted with : Speaker on the conforming type's declaration; a struct with an identical speak() method but no stated conformance does not satisfy Speaker and will not compile where one is expected.

TypeScript's type alias for an object shape and its interface are close cousins, both satisfied structurally. Swift has no structural counterpart at all — a shape-only contract must be a protocol, requiring explicit, nominal conformance from every adopting type. Swift typealias exists but only renames an existing type; it cannot define a new structural shape.

Swift protocol extensions let a protocol supply a default method implementation that every conforming type receives automatically, and may override. TypeScript interfaces are pure shape declarations with no method bodies at all — shared behavior must come from a base class (reintroducing reference-type inheritance) or a standalone helper function, since TypeScript has nothing structurally equivalent to a protocol extension.

TypeScript composes multiple interfaces with the intersection operator & on a type alias. Swift uses the same & syntax for an anonymous protocol composition in a parameter position, and lists multiple protocols comma-separated after a type's name when declaring conformance — a close syntactic parallel once you know TypeScript's & is doing double duty across both languages.

This pairing is the closest conceptual parallel between the two languages. A TypeScript discriminated union tags each variant object with a literal kind field the developer must define and check by hand. A Swift enum with associated values is a first-class sum type built into the language — the compiler, not a hand-maintained tag field, guarantees the switch is exhaustive and each case's payload is correctly typed.

A TypeScript string literal union ("north" | "south" | ...) is the idiomatic way to express a closed set of named options, but it is still just strings under the hood — nothing stops a stray typo'd string from being coerced elsewhere in a loosely typed codebase. A Swift enum is a genuinely distinct type; Direction.north is not a String at all, and the compiler catches any confusion between the two.

TypeScript's numeric enum is really just an object with forward and reverse key mappings baked in by the compiler. Swift's raw-value enum (enum Status: Int) exposes the backing value through .rawValue and offers a failable initializer, Status(rawValue:), that returns an Optional rather than assuming the raw value is valid — safer than TypeScript's implicit reverse mapping, which has no failure case built in.

TypeScript can catch a missing discriminated-union case, but only when the function's return type and a strict compiler configuration line up just right — it is a best-effort analysis, not a language guarantee. Swift's switch exhaustiveness over an enum is enforced unconditionally: the compiler rejects the build outright if any case is unhandled and there is no default. The commented-out lines above illustrate the point being made rather than code meant to execute — actually omitting the case would fail to compile in either language — so this example is marked non-runnable.

The angle-bracket generic syntax <T> is shared between the two languages and the concepts map closely. The crucial difference is underneath: TypeScript generics are fully erased during compilation, while Swift generics are reified — the concrete type argument exists at runtime, which is part of why Swift generic code compiles to efficient, specialized machine code rather than operating on erased, boxed values.

TypeScript constrains a generic parameter with extends; Swift uses a colon in a where-style clause, here shortened to T: Comparable. Swift's standard library already makes the built-in numeric and string types conform to Comparable, so maxOf works on plain Int values directly, without the wrapper class TypeScript's example needed to satisfy a hand-written Comparable<T> interface.

Swift's switch can match directly on a tuple, using _ as a wildcard for positions to ignore. TypeScript's switch can only compare a single value at a time, so the equivalent logic requires an if/else if chain, as shown here.

Swift switch cases accept ranges directly as patterns (90...100 inclusive, 80..<90 exclusive) and a where clause can attach an arbitrary extra condition to a case, as in case let value where value >= 70. TypeScript has no pattern-matching construct that reaches this expressiveness; range and conditional logic both fall back to plain if/else if chains.

Switching on a Swift enum with associated values both narrows the case and extracts its payload into a named binding in one step — case .text(let content). The TypeScript discriminated union achieves a similar narrowing effect through the type tag field, but each variant's properties must be accessed separately after the tag check rather than bound directly by the pattern.

TypeScript has no typed-throws mechanism at all: a function can throw any value of any type with no signature-level declaration, and a catch block receives that value typed unknown, requiring a cast to use it safely. Swift requires a throwing function to be marked throws in its signature, requires try at every call site, and lets errors conform to the Error protocol so a catch clause can pattern-match specific error cases directly.

try? converts any throwing call into an Optional — nil on failure, the value otherwise — collapsing a whole do/catch block into one expression. TypeScript has no equivalent shorthand; the closest pattern is a hand-written helper, like the one shown here, that manually converts a failure signal into null. Swift also has try!, which force-unwraps the result and crashes at runtime if an error is actually thrown — use it only when failure is truly impossible.

A Swift error enum with associated values bundles structured data directly onto each case, and a catch clause can both match a specific case and bind its payload in one step. TypeScript's custom error classes achieve something similar by attaching extra properties, but require an instanceof check inside a single generic catch block rather than dispatching to a distinct pattern per error kind.

This is the smoothest transition in the whole comparison: Swift's async/await surface syntax reads almost identically to TypeScript's. Swift marks a function async after its parameter list rather than before function, and top-level Swift code can await directly with no wrapping async function required, unlike this TypeScript example which needs an async main to use top-level await safely across environments.

JavaScript's single-threaded event loop means "concurrent" async functions only ever interleave at await points, so ordinary shared variables can never experience a genuine data race — TypeScript inherits this guarantee for free. Swift's structured concurrency (Task, task groups, async/await) can run work on real OS threads in true parallel, so the language introduces actor types that serialize access to their own mutable state and the compiler enforces those boundaries — a strictness with no TypeScript counterpart, because TypeScript never needed one.

Because TypeScript types vanish entirely at runtime, a lying type assertion (as Config) is accepted by the compiler and produces no error anywhere — the mismatch surfaces later as silent, confusing behavior, like string concatenation where arithmetic was expected. Swift's equivalent operation, decoding untrusted data with Codable, genuinely validates the data against the real, runtime-present type and throws a catchable error the moment the shape does not match.

Both languages let a careless force-unwrap fail at runtime, but the failure modes differ in severity and clarity. TypeScript's ! assertion is erased at compile time; a wrong assertion surfaces later as a generic TypeError at whatever point the value is actually used, potentially far from the mistaken assertion. Swift's ! traps immediately, at the exact unwrap site, with an unambiguous "unexpectedly found nil" message — a design that treats a broken invariant as a bug to fix rather than a value to keep passing along.

A TypeScript programmer's instinct — "passing an object into a function lets that function mutate the caller's data" — is simply wrong for a Swift struct passed by value: the function receives an independent copy, and mutating it (even after making the parameter a local var) never affects the original. To let a function intentionally mutate the caller's struct, Swift requires the parameter to be marked inout and the call site to pass it with an explicit & — making the mutation visible and opt-in rather than implicit.

Swift enforces two-phase initialization: every stored property on a class or struct must be assigned a value before the initializer finishes and before self can be used in most contexts, or the code simply does not compile. TypeScript's "definite assignment" checking is comparatively permissive — it primarily verifies a property is set somewhere before first read, without Swift's stricter guarantee that construction is atomic and a half-built instance can never be observed.