Swift.CodeCompared.To/C#

Modern C# has top-level statements, so a program no longer needs a class and a Main method — this is the whole file, exactly as in Swift. Semicolons are mandatory, and the implicit using directives (System, System.Linq, System.Collections.Generic, …) are added for you, which is why Console and List<T> just work.

The false friend arrives immediately: C#'s var means inferred, not mutable, so it covers both of Swift's keywords and carries none of the meaning. Immutability for a local is const (compile-time constants only) or readonly on a field — there is no general let, and the immutable-by-default discipline you have in Swift becomes a convention you keep by hand. Interpolation is $"{expression}", and C# 11 raw string literals strip the indentation from the closing delimiter, exactly like Swift's multi-line strings.

What C# adds is a format specification after a colon — {value:F2}, {count:N0}, {date:yyyy-MM-dd} — which replaces the String(format:) call Swift makes you drop to. What it lacks is Swift's ExpressibleByStringInterpolation, so you cannot teach the interpolation how to handle your own type; the value is simply ToString()d. Interpolated strings are also compiled into an efficient builder rather than concatenation, so they are the fast path as well as the readable one.

The practical consequence is that C# cannot overload on labels the way Swift does — move(from:to:) and move(from:by:) are different methods in Swift, and in C# they would be one signature. What C# gains is that reordering is allowed (Move(to: 9, from: 1) compiles), and that a long parameter list can be clarified at the call site without the API author having planned for it. Optional parameters with defaults cover most of what Swift does with several overloads.

The syntax will lull you. ?., ??, ??= and ! all mean what you expect, and is string name is a decent if let. But nullable reference types are a static analysis, not a type: string and string? compile to the same runtime type, the checking produces warnings rather than errors (and is off entirely in older projects), and every string can still hold null if it came from a library that was not annotated, from reflection, or from deserialization. Swift's String? is a genuinely different type that the runtime knows about. The practical advice: turn on <Nullable>enable</Nullable> and TreatWarningsAsErrors in your project file, and treat ! the way you treat try!. (Nullable value types — int? — are real: they are Nullable<int>, a struct, and they do exist at run time.)

Swift's optionals are sound: a non-optional cannot hold nil, full stop. C# added nullable reference types to a language with twenty years of existing code, so the compiler tracks nullability and can only warn — and the annotation is erased at run time, so nothing checks it there either. Three things follow. Turn on <Nullable>enable</Nullable> and <TreatWarningsAsErrors>, or the feature is documentation. The null-forgiving operator ! is as! with no run-time check at all. And a library compiled without the feature reports everything as oblivious, so its nulls arrive unannounced.

text is not { Length: > 0 } is a property pattern, and it is the closest C# gets to guard let value = text, !value.isEmpty in one expression. What is missing is the compiler requiring the else branch to exit — a C# if that falls through simply continues, so the shape is a convention rather than a rule. ArgumentNullException.ThrowIfNull(text) is the idiomatic one-liner when the answer is to throw.

A struct is a value type and a class is a reference type, exactly as in Swift, and the assignment semantics follow. Two differences worth carrying. C# structs have no copy-on-write: a copy is a real, eager copy of the bytes, so a large struct is genuinely expensive to pass around (Swift's Array is a struct precisely because COW makes that cheap; a C# List<T> is a class). And indexing a collection of structs hands you a copy, so mutating it changes nothing — the source of a classic C# head-scratcher, and the reason the community convention is readonly struct with immutable fields.

A record is C#'s data type: value equality, a readable ToString, deconstruction, and the with expression — and note the last one, because Swift has no equivalent. ada with { Age = 37 } produces a modified copy in one expression, which is exactly what you want from an immutable value and what Swift makes you write a full initializer call for. A plain record is a class (a reference type) that merely compares by value; record struct is the value type. For a Swift developer, record with all-init-only properties is the closest thing to the struct you would have written.

This catches every Swift developer at least once, because the value-type intuition transfers perfectly to struct and not at all to collections. The defenses are the ordinary ones: copy at the boundary (new List<int>(other)), hand out IReadOnlyList<T> so a caller cannot modify what you own, or use the genuinely immutable System.Collections.Immutable types. What you get in exchange is that no copy ever happens behind your back — C#'s cost is visible where Swift's is amortized and occasionally surprising.

🚨 That inversion has a performance consequence with no Swift equivalent: calling a non-readonly method on a readonly field or an in parameter makes the compiler emit a defensive copy of the whole struct, silently, on every call. Marking every non-mutating struct method readonly is therefore not pedantry — it is how you avoid copies you never asked for. The compiler will tell you where with warning CS8656 if you enable it.

Properties are a first-class feature in both languages, and the translation is mostly mechanical: var area: Double { … } becomes public double Area => …, and the object-initializer syntax (new Rectangle { Width = 3 }) plus init-only setters gives you something very close to a Swift memberwise initializer with let properties. Two things get more verbose: there are no property observers (didSet/willSet become a hand-written property with a backing field, where value is the implicit setter parameter), and there is no lazy var keyword — Lazy<T> is a library type that does the same job with more ceremony.

Two C# additions worth adopting. { get; init; } makes a property settable only during object initialization, which is closer to a Swift let on a struct than readonly is. And the object-initializer syntax — new Rectangle { Width = 3 } — is how C# replaces Swift's memberwise initializer, since it does not generate one. What you lose along with didSet is willSet, lazy var, and property wrappers, which have no counterpart at all.

Two losses. A C# enum is a thin wrapper over an integer: no associated values, no string raw values (an attribute or a dictionary does that job), and — startlingly — not a closed set, since (Status)99 is a legal Status. And a sum type with payloads becomes an abstract record hierarchy plus a switch expression, which reads well (the pattern matching is genuinely good) but does not give you Swift's exhaustiveness: the compiler can warn when it proves a case is unhandled, and idiomatic code still writes the _ discard arm, so adding a third shape usually falls through silently.

C#'s pattern matching has quietly overtaken Swift's. Everything you know is here — type patterns, when guards (Swift's where), tuple patterns — plus three things Swift lacks: property patterns (string { Length: 0 }, matching on a member without binding the whole value), relational patterns (> 0, < 0, combinable with and/or/not), and list patterns ([var first, .., var last]). The switch expression (with => arms and a trailing comma) is the modern form, and it is what you will write.

Records plus a switch expression get you close, and the gap that remains is exhaustiveness: the _ => throw arm exists because C# cannot prove the list is complete, so adding a third shape produces a run-time exception rather than a build error. Sealing the hierarchy helps a little — mark the base abstract and the cases in one file — and C# still will not check it. That discard arm is the idiom precisely because it turns a silent wrong answer into a loud failure.

Interfaces with default methods are protocol extensions, and interface properties (string Name { get; }) cover protocol properties. Two differences a Swift developer will notice. The I prefix is a hard convention (IDescribable, IEnumerable) and everyone follows it. And C# has no retroactive conformance: you cannot make an existing type implement an interface from outside, which is the trick Swift extensions do all the time — the C# workaround is an adapter class or an extension method, and neither is as good.

Same feature, more ceremony: an extension method is a static method in a static class whose first parameter is marked this, and it is dispatched statically (as in Swift). The gap is extension properties — C# has none, so text.Initials must become text.Initials(). This is also the mechanism behind LINQ: Where, Select and the rest are extension methods on IEnumerable<T>, which is why they appear on every collection in the language.

This is the deepest difference between protocols and interfaces, and it changes design. A Swift library can say "anything Codable" and a user can retrofit an existing type; a C# library must either be handed an interface the type already implements, or take a delegate, or use generic constraints with a helper. .NET's usual answers are a delegate parameter (Func<T, string>), an adapter class, or — since .NET 7 — static abstract interface members, which are how INumber<T> finally made generic math possible.

The vocabulary shifts (filter is Where, map is Select, reduce is Aggregate or a specialized Sum), and the evaluation model flips: LINQ is lazy, so a chain builds a query and nothing executes until a terminal operation (ToList, First, Sum, a foreach) pulls on it. That is Swift's .lazy, on by default. Two traps: iterating the same query twice re-runs it (call .ToList() to materialize), and indexing a Dictionary with a missing key throws rather than returning an optional — TryGetValue or GetValueOrDefault is the safe form.

🚨 Two consequences a Swift developer will meet. Enumerating a query twice executes it twice — including any database round trip — which is why ToList() at the end of a chain is so common in real code. And a closure capturing a variable that later changes will see the new value, because the chain runs at consumption time rather than at definition. In exchange, chaining ten operations makes one pass rather than nine intermediate arrays, and IQueryable lets the same syntax be translated into SQL — which Swift has no counterpart for.

The pairs worth memorizing: sorted() is OrderBy, first(where:) is FirstOrDefault, allSatisfy is All, contains(where:) is Any, compactMap is Where(x => x is not null).Select(…), flatMap is SelectMany, and Set deduplication is Distinct. 🚨 FirstOrDefault without the default argument returns default(T) — which is 0 for an int, not null — so an empty result and a legitimate zero are indistinguishable unless you pass one.

All exceptions are unchecked and none of them appear in a signature, so the information Swift puts in the type system (throws) simply is not there — you learn what can fail from the documentation or from production. In exchange the happy path is uncluttered by try. Two idioms are worth adopting: exception filters (catch (Exception e) when (…)), which let you inspect before catching rather than catching and rethrowing; and the Try-pattern (int.TryParse(text, out var number)), which returns a bool instead of throwing and is the standard-library answer for failure you expect — the closest thing to try?.

The Try pattern is everywhere in .NET precisely because throwing for an expected failure is expensive, and its limitation is that a bool can say something went wrong but not what. There is no Result type in the standard library either, so a method that needs to explain a failure throws. The one thing C# gives you that Swift does not is an exception filter: catch (Exception error) when (error.Message.Contains("timeout")) tests a condition without unwinding first, which has no Swift equivalent.

The difference is where the obligation lives. Swift's defer can clean up anything — a flag, a counter, a lock you took by hand — while using needs a disposable type, so an arbitrary "run this on the way out" becomes try/finally. Going the other way, using puts the cleanup in the type so a caller cannot forget it, which defer cannot do. await using is the asynchronous form, and has no Swift counterpart.

The .NET runtime uses a tracing garbage collector, so three Swift habits go away. Cycles are not a leak — weak and unowned have no counterpart and no purpose (WeakReference<T> exists, but for caches, not for breaking cycles). There is no deinit: finalizers exist, run nondeterministically, and are actively discouraged. And there is no defer — cleanup attaches to a resource that implements IDisposable, and using calls Dispose() on every exit path. The trade is the same one every GC language makes: you stop thinking about retain cycles and start thinking about which objects hold unmanaged resources.

That removes a whole category of Swift design work — no capture lists, no [weak self], no delegate-must-be-weak rule. What you give up is deinit: a C# finalizer runs at an unpredictable time on a separate thread, may never run at all, and makes an object take two collections to die. 🚨 Do not write one. Anything with a lifetime gets IDisposable and a using, which is the previous row. C# does have WeakReference<T>, and it is for caches rather than for breaking cycles.

The syntax is identical and the semantics differ in ways that matter. A Task is hot: calling an async method starts the work immediately, so there is no lazy async { } and no scope that owns it — a forgotten task leaks rather than being canceled with its parent. There is no structured concurrency: Task.WhenAll waits, but nothing forms a tree, and cancellation is a CancellationToken you thread through every call by hand where Swift propagates it down the task tree for free. On the other side of the ledger, .NET has real parallelism with no GIL, and Task.WhenAny gives you a race that Swift needs a task group to express. There are no actors — lock, Interlocked, or a Channel<T> do that job, and none of them is checked by the compiler.

This is the clearest place Swift is ahead, and the gap widened with Swift 6's strict concurrency checking. C#'s equivalents are all conventions and libraries: lock, the System.Collections.Concurrent types, Interlocked, and SemaphoreSlim for the asynchronous case — since 🚨 you must never lock across an await, which the compiler will not stop you doing. A data race in C# gives you a wrong value; in Swift 6 it gives you a compile error.

Structured concurrency means a Swift child task cannot escape its scope and inherits cancellation automatically. In C# both are your responsibility: a forgotten await produces a fire-and-forget task whose exception is never observed, and cancellation only reaches a child if you threaded the token to it. The compensation is that CancellationToken is a framework-wide convention every async .NET API accepts, and CancellationTokenSource composes with timeouts and linked tokens more flexibly than Swift's cooperative model does.