C#.CodeCompared.To/Swift

Both languages run top-level statements with no Main ceremony. print replaces Console.WriteLine, and semicolons are optional (and omitted by convention).

let is a genuine read-only binding — assignable once, from any runtime value — which C# locals cannot express (const handles only compile-time constants). Swift style is let everywhere; the compiler suggests demoting any var that is never mutated.

Inference looks the same, but Swift performs no implicit numeric conversions at all — not even Int to Double. Every mixed-type expression needs an explicit constructor call like Double(quantity), a strictness beyond anything in C#.

The shared headline with Kotlin, and the biggest safety upgrade from C#: String? is a distinct type (Optional<String>, a real enum), and using it without unwrapping refuses to compile. C#’s nullable annotations warn and vanish at runtime; Swift’s optionals are values the runtime actually represents.

if let unwraps and binds in one step — inside the braces, stored is a non-optional String. The shorthand if let stored (no right-hand side) shadows the optional with its unwrapped self, the closest analog to C#’s flow-narrowing after is not null.

guard is the early-return check made a language feature: its else block must exit the scope, and in exchange the unwrapped binding survives for the rest of the function — the inverse scoping of if let, and the backbone of idiomatic Swift function bodies.

The operators you already use daily transfer verbatim: ?. short-circuits on absence, ?? supplies the fallback. The difference is that the compiler forces the chain to end in a fallback or an unwrap — the optional never leaks silently.

C#’s null-forgiving ! is erased; a wrong one lets null flow on to crash somewhere else. Swift’s force-unwrap performs a real check and stops the program at that line with a clear message. Both are last resorts — Swift’s at least fails at the scene of the crime.

C# has structs but reserves them for small, niche types; in Swift the culture inverts — struct is the default modeling tool and class the special case for identity and sharing. Note the free memberwise initializer Point(x:y:): no constructor boilerplate.

The standard collections — String, Array, Dictionary, Set — are all structs. Assignment copies (lazily, via copy-on-write), so the aliasing bugs C# collections invite simply cannot happen. Sharing must be chosen explicitly with a class.

A struct method that changes state must be declared mutating — and calling it on a let struct is a compile error. C# lets struct methods mutate silently (the classic source of "modified a copy" bugs); Swift makes value mutation visible in the signature and impossible on immutable bindings.

Because arrays are value types, let freezes the whole value — there is no C#-style "readonly reference to a mutable list" gap. Immutability is decided at the binding, not the type: the same Array type is frozen under let and mutable under var.

Every Swift string literal interpolates — no $ prefix to remember. The delimiter is \(expression), and any expression fits inside. Formatting alignment/precision uses String(format:) or formatted values rather than C#’s {value:F2} inline syntax.

Triple-quoted strings work almost identically — including the indentation stripping keyed off the closing delimiter, which C# 11 borrowed from Swift’s design. Swift’s version still interpolates \(…); for regex-heavy content, #"raw"# delimiters disable escaping.

C#’s Length counts UTF-16 code units — the family emoji is 11 of them. Swift’s count counts grapheme clusters (what a person sees) by default, with unicodeScalars/utf8/utf16 views when you need the underlying encodings. The price: Swift strings are not integer-indexable (text[0] does not compile).

The literal syntax […] replaces the new List<string> { } ceremony, and printing an array shows its contents (no string.Join needed). Note the argument label in remove(at: 0) — labels are part of the method name.

A dictionary lookup returns an optional, so the missing-key case is handled with ?? or if let instead of C#’s exception-throwing indexer and the TryGetValue/out dance. The optional system absorbs a whole API pattern.

The LINQ verbs exist under FP names — Where → filter, Select → map, Aggregate → reduce. Trailing closures drop the parentheses, $0 is the implicit parameter, and operators like + pass directly as functions (reduce(0, +)).

Swift’s collection operators are eager — each step builds an array — where LINQ defers by default. The .lazy view opts back into LINQ-style element-at-a-time evaluation; prefix is Take. The instinct to keep: reach for .lazy on long chains with early exits.

Two small changes: no parentheses around the condition, and braces are required even for one-liners (the classic dangling-else and goto-fail bugs are unrepresentable). The ternary operator survives unchanged — unlike Kotlin, Swift kept it.

Swift removed the C-style for (;;) loop entirely — iteration is always for‑in over a sequence, with ranges (1...5 inclusive, 1..<5 half-open) covering the counting cases. stride(from:to:by:) handles arbitrary steps.

guard works with any condition, not just unwrapping: state the requirement positively, and the compiler enforces that the else branch exits. Function bodies become a flat list of preconditions followed by the happy path — no arrow-shaped nesting.

Swift’s switch is the statement form of C#’s switch expression: no fallthrough (no break needed), comma-separated alternatives, range patterns, and compiler-enforced exhaustiveness. Where C# still carries the legacy fallthrough statement form, Swift has only the safe one.

The pattern vocabularies have converged remarkably: tuple patterns, binding (case let vs var (x, y)), guards (where vs when), and wildcards. Swift checks tuple-pattern exhaustiveness here without a default because the bound case matches anything.

if case applies one pattern outside a switch — the analog of C#’s is-pattern in an if. The comma chains further conditions the way C# uses && after a pattern. Most commonly used to pluck one enum case’s payload without a full switch.

The single biggest upgrade over C# enums: Swift enum cases carry typed payloads, making the enum a true sum type — what C# fakes with an abstract record hierarchy. The switch is exhaustive with no defensive _ arm, and adding a case breaks every non-exhaustive switch at compile time.

C#’s named-integer style still exists as raw values, opted into per enum. CaseIterable synthesizes allCases (C#’s Enum.GetValues), and LogLevel(rawValue: 2) converts back — returning an optional, naturally, since the integer might match nothing.

The polarity flips: C# names arguments when the caller feels like it; Swift requires labels unless the declaration opts out with _ (func resize(_ width: Int, …)). Labels are part of the function’s identity — resize(width:height:) — which is why Swift APIs read like sentences.

params becomes the Int... variadic, arriving as an array in the body. Because labels disambiguate, a variadic does not have to be last — a labeled parameter can follow it, which C#’s params cannot allow.

The closure literal is braces with an in separating signature from body; $0/$1 are the implicit parameters. When the last argument is a closure, it moves outside the parentheses (trailing-closure syntax) — the shape SwiftUI’s entire DSL is built on.

Named tuples rhyme almost perfectly with C#’s ValueTuple — labels in the return type, destructuring at the call site. The ! after min()/max() force-unwraps the optional those methods return for a possibly-empty array; production code would guard instead.

Classes are reference types in both languages — but in Swift you reach for one only when identity or sharing is the point. init replaces the constructor, there is no new, and note that a let holding a class instance still permits mutating its state (the reference is constant, not the object — exactly like C# readonly).

Protocols are interfaces without the I prefix — and structs conform as readily as classes, so polymorphism does not require reference types. The any Speaker spelling marks an existential (heterogeneous) collection explicitly, a distinction C# leaves implicit.

Protocol extensions are Swift’s signature move — shared behavior attached to the protocol itself, inherited by every conforming type and callable directly on the concrete value (no interface-reference restriction like C#’s default interface methods). Large parts of the standard library are protocol extensions on Sequence and Collection.

An extension can add a protocol conformance to any existing type, including the standard library’s — no wrapper, no ownership required. This is the capability C# extension methods approach but never reach: they add methods, but the type never becomes an implementer of the interface.

A read-only computed property is just a braced body after the type — the analog of C#’s expression-bodied => member. Add explicit get/set blocks for read-write computed properties; stored and computed properties are otherwise declared identically.

Property observers attach to a stored property — no backing-field ceremony, no custom setter. willSet sees the incoming newValue, didSet the departed oldValue. C# expresses the same thing only by expanding the auto-property into a manual one.

Two honesty upgrades over C#: a function that can throw says so in its signature (throws), and every call to it must be marked try — the invisible exception paths that plague C# codebases are syntactically impossible. Catch clauses pattern-match on error cases, payloads included.

try? converts any thrown error into nil, folding the whole TryParse pattern into the optional system — one throwing function serves both styles, instead of C#’s parallel Parse/TryParse method pairs. try! asserts no error will occur and traps if one does.

defer schedules cleanup for scope exit — return, throw, or fall-through — right next to the acquisition it balances, with multiple defers unwinding in reverse order. It covers what C# splits between finally and using, without tying cleanup to a try block or an IDisposable.

Swift uses automatic reference counting, not a tracing GC: the moment the last reference disappears, deinit runs — deterministically, like C++ RAII. The whole IDisposable/using apparatus exists because C# finalizers cannot promise that; in Swift the destructor alone suffices.

The price of ARC’s determinism: reference cycles leak, because each object keeps the other’s count above zero. Back-references are declared weak (an optional that becomes nil when the target dies) or unowned. The same discipline applies to closures capturing self — the [weak self] capture list you will meet everywhere in UI code.

The closest concurrency rhyme on this page: async/await transfer almost keyword-for-keyword, and Swift’s return type stays unwrapped (String, not Task<string>). Note async throws composing with try await — effects stack explicitly in the signature and at the call site.

async let starts child tasks that run concurrently and must be awaited before the scope ends — structured concurrency the compiler enforces, where Task.WhenAll is a convention the programmer maintains. For a dynamic number of children, withTaskGroup is the scaling version.

An actor is a reference type whose state is isolated: all access is serialized by the runtime, and cross-actor calls must be awaited. Where C#’s lock is a discipline the compiler never checks, Swift 6’s strict concurrency makes unsynchronized shared mutation a compile error — the data race, not the deadlock, becomes impossible.