Dart.CodeCompared.To/Swift

Swift permits statements at file scope, so a script has no entry function at all — the top-level code just runs, top to bottom. This is a bigger departure than it looks: any helper func or struct is declared alongside the top-level statements that use them, and there is no void main() to wrap them in.

Dart's final is let and var is var. The meaning of let is stronger than final when it holds a value type, though: a let on a struct makes the whole value immutable, including its properties, whereas Dart's final only fixes the binding to a mutable object. That distinction drives the next section.

The idea is the same but the syntax is unusual: Swift wraps every interpolation in \(…) — a backslash and parentheses — with no bare-variable shorthand like Dart's $name. There is one form for both a simple variable and a full expression, which is at least consistent.

Two changes bite a Dart programmer. There is no ~/: / on two Ints already truncates, and you force floating point by making an operand a Double. And Swift does no implicit numeric conversion — Double(count) + 0.5 must convert explicitly, where Dart quietly promotes an int to a double. There is also no num supertype.

A Dart class assignment aliases one object, so mutating second changes first. A Swift struct assignment copies, so the two are independent — the model Dart has no equivalent for. Swift also has class (a reference type, like every Dart class), but the community default is struct: reach for class only when you specifically need shared identity.

Because a struct is a value, a method that changes it must be marked mutating, and you can only call such a method on a var — a let struct is fully frozen, properties and all. This is stricter than Dart, where final counter still lets you call mutating methods because final only pins the reference, not the object's contents.

A nullable String? is a Swift Optional (also written String?), and the absent value is nil. The idiomatic unwrap differs from Dart's flow promotion: if let name = findName(1) binds a non-optional name for the block only if the value is present. Swift optionals are sound, like Dart's null safety — there is no platform-type escape hatch.

Two operators port over unchanged: ?? supplies a default and ! force-unwraps (trapping at run time if nil, exactly like Dart's !). Swift adds one tool Dart lacks — guard let … else { return } — which unwraps into the enclosing scope and forces you to handle the absent case up front, keeping the happy path unindented.

Dart's lazy late (compute on first access) is Swift's lazy var, which likewise defers the initializer until the property is first read. Note it must be a var (reading it mutates the stored state), so a lazy property makes its containing struct mutable. Dart's other late — deferred-but-non-lazy — maps to a Swift implicitly-unwrapped optional (var x: String!).

ARC frees a class instance deterministically — the instant its reference count hits zero — which is why the deinit for main runs the moment it is replaced, something a Dart finalizer can never promise. ARC applies only to classes; value types (structs, enums) are copied and need no counting. The cost is that ARC cannot break reference cycles on its own, which the next concept addresses.

Here Dart is simpler: a tracing collector reclaims cyclic garbage automatically, so a parent/child back-reference needs no thought. Under ARC a strong cycle never reaches zero and leaks, so you must mark one side weak (auto-nils when the target is freed) or unowned (assumed to outlive you). Learning where to place weak — especially in closures that capture self — is the main new discipline for a Dart programmer.

A Swift enum case can carry associated values, so the whole Dart sealed hierarchy collapses into one enum Shape — exactly the feature Dart's enum lacks. A switch over it is exhaustive (omit a case and it fails to compile) and binds the payload inline with case .circle(let r), which is close to Dart's object pattern. Swift enums also do the plain job via raw values (enum Direction: String).

Dart's enhanced enum with a per-constant value becomes a Swift raw-value enum: enum Planet: Double attaches a Double to each case, read back through the built-in rawValue property. Methods are declared inside the enum in both languages. Reach for a raw-value enum when each case maps to one constant, and associated values (previous concept) when cases carry structured data.

A Swift constructor is init, but a struct gives you a memberwise initializer for free — Rectangle(width:height:) here needs no code, and every argument is labeled by default. A computed property uses a braces-block getter, var area: Int { … }. There is no new keyword, so construction reads like a function call, as in Dart.

Swift's protocol is Dart's interface/abstract contract, and conformance is declared after the colon (struct Dog: Speaker). The big idea Swift adds is that a struct or enum — not just a class — can conform, so protocols are the primary abstraction rather than base classes. Unlike Dart, every class does not automatically define an implicit interface.

Dart mixes shared behavior in with with. Swift's equivalent is a protocol extension: declare the requirement in the protocol, then supply a default method in an extension Greetable that every conformer inherits. This "protocol-oriented" style is Swift's answer to both mixins and abstract base classes, and it works for value types too.

Swift has no cascade operator, so there is no direct stand-in for Dart's ... You repeat the receiver, or — the closest idiom — configure inside a closure: let basket = { var b = Basket(); b.add("apple"); return b }(). For class-based builder APIs you can still hand-roll a fluent chain by returning self, but there is no language-level cascade.

This is one of the closest matches on the page: a Dart positional record (int, String) is a Swift tuple (Int, String), destructured the same way with let (a, b) = …. Swift tuples can also name their elements — (x: Int, y: Int), accessed as point.x — mirroring Dart's named records almost exactly. The difference is scale: Swift tuples are best kept small, with a struct preferred past two or three fields.

Dart's named record fields map directly to a Swift named tuple, and both read their members by label (size.width). It is a lightweight way to return a couple of labeled values without declaring a type — but once the shape is reused or grows, both communities steer you toward a real struct/record type instead of passing tuples around.

Where Dart parameters are positional unless wrapped in { }, Swift labels every argument by default — move(x: 3, y: 4) — and the labels are part of the function's identity. To make one positional you write an underscore before it (func move(_ x: Int)), and you can give a separate external label (func greet(to name: String) called greet(to: "Ada")). Defaults work as in Dart.

Swift closures use braces, and when a closure is a function's last argument it moves outside the parentheses — the trailing-closure form, so filter { … }. Inside, positional arguments are available as $0, $1, … without naming them, tighter than Dart's (n) =>. The methods rename slightly: Dart's where is filter, and map is the same.

Extensions survive the trip. Swift's extension Int { … } adds a computed property to an existing type just like Dart's extension … on int, and self plays the role of Dart's this. Swift goes further: an extension can also add protocol conformance to a type you do not own, which is central to its protocol-oriented style.

Both languages have an exhaustive, pattern-based switch, and they are strikingly similar. Swift uses case/default and ranges (1...3) where Dart uses =>/_ and || alternatives, and both support a value binding with a guard: Swift's case let v where v < 0 is Dart's final v when v < 0. Swift cases do not fall through by default, so no break is needed.

Swift matches tuples structurally, binding pieces with let and matching literals in place — case (let x, 0) is Dart's (final x, 0) almost verbatim. This is the same destructuring-while-matching that Dart 3 patterns brought, and it is one of the areas where the two languages feel most alike, down to wildcard positions and value bindings.

In Dart a List is a reference, so second.add(4) is visible through first. In Swift the built-in collections are value types: second is a copy, and mutating it leaves first alone. Swift implements this efficiently with copy-on-write, so the duplication only happens on the first mutation — but the semantics you must reason about are full value copies.

A Swift dictionary literal uses colons, ["Ada": 36], and indexing returns an Optional — ages["Ada"] is Int?, so you commonly pair it with ??, where Dart just hands back null. Iteration yields (key, value) tuples you can destructure in the for. Like all Swift collections a Dictionary is unordered, so this example sorts for stable output.

Swift's reduce(initial) { … } takes a seed of any type, so it plays the role of Dart's fold. There is no separate seedless reduce like Dart's; for the common aggregates Swift ships dedicated methods — max(), min(), and (for numbers) reduce(0, +) — which return optionals and read more clearly than a hand-written fold.

This maps almost one to one: a Dart async function returning Future<int> is a Swift func … async -> Int, and await means the same on both sides. Two spelling notes: Swift writes the effect in the signature (async, before the return arrow), and a delay is Task.sleep. Swift also permits top-level await, so no wrapper is needed here.

To run work concurrently and then await it together, Swift offers async let: each binding starts immediately, and awaiting them (here in an array literal) joins the results — the structured-concurrency equivalent of Dart's Future.wait. For a dynamic number of tasks Swift uses a TaskGroup instead, where Dart would map over a list into Future.wait.

A Dart Isolate has a private heap and communicates by copying messages, so there is no shared state to race. A Swift actor instead owns its mutable state and serializes every access, so calls into it are awaited (they may suspend) and the compiler stops you from touching its state directly. Different mechanisms, same goal — safe concurrent state — and both spare you manual locks for the common case.

Swift marks a throwing function with throws in its signature and forces the caller to write try at the call site — a visibility Dart does not require. A conforming error is any type adopting the empty Error protocol. The handler is do { … } catch { … }, and the caught value is available as the implicit error binding without you naming it.

Swift adds two terse call-site forms that Dart lacks. try? turns a throw into nil, collapsing a whole try/catch into an optional — the pattern the Dart column has to write by hand. try! asserts the call cannot fail and traps if it does, the error-handling cousin of force-unwrap !. Both keep the marked-try discipline while trading detail for brevity.

Swift's unit of import is a module (a whole library or target), not an individual file, so files within the same target see each other with no import at all — quite different from Dart's per-file import. You import Foundation or another package by module name. Visibility is controlled with public/internal/private keywords rather than Dart's leading-underscore convention. The Dart side references a second file, so its column is display-only.

Dart's pubspec.yaml plus dart pub get corresponds to a Package.swift manifest plus swift build using the Swift Package Manager. The manifest is itself written in Swift (not YAML), and dependencies are resolved straight from Git URLs and tags rather than from a central registry like pub.dev.