Swift.CodeCompared.To/Dart

Dart has no top-level statement mode: execution begins at a required void main(). Swift lets you write statements at file scope; Dart insists on the entry-point function, and every statement ends in a semicolon.

Comment syntax is identical, including the triple-slash /// documentation comment. Dart’s doc comments feed dart doc the way Swift’s feed DocC.

Both use print, but the interpolation sigil differs: Swift’s \(expr) becomes Dart’s $name for a bare identifier and ${expr} for anything more complex.

Swift’s let maps to Dart’s final, and var is mutable in both. The keyword flips: in Swift the short word (let) is the immutable one, in Dart the short word (var) is the mutable one.

Dart draws a distinction Swift does not: final is set once at run time, while const must be known at compile time and is canonicalized — two identical const values are the same object. This underpins Dart’s const constructors.

Both infer from the initializer. The annotation position differs: Swift writes name: Type, Dart writes Type name — the type precedes the name, C-style.

Dart’s dynamic turns off static checking for that variable: any method call compiles and is resolved at run time, throwing NoSuchMethodError if absent. Swift’s Any has no such hole — you must cast with as? before sending a message.

Dart has sound null safety like Swift: String? is the nullable type and ?? is the same coalescing operator. The difference is spelling — Swift’s Optional<T> is a real enum you can pattern-match, while Dart’s T? is a union of T and Null.

Dart has no if let; instead a != null check promotes the variable to its non-nullable type for the rest of the branch, so you keep using the same name. Promotion works only on local variables, not on mutable fields.

The operators line up almost exactly: ?. for safe access and postfix ! to assert non-null. Swift calls ! "force unwrap"; Dart calls it the "null assertion operator", and both crash if the value is actually absent.

Dart’s late promises the compiler a non-nullable variable will be assigned before it is read, deferring the check to run time — the nearest match to Swift’s implicitly-unwrapped optional (String!), but without leaving the variable nullable. Paired with an initializer it also gives lazy, compute-on-first-read initialization, the role Swift’s lazy var fills inside a type.

A bare variable interpolates as $name, but any expression needs the braces: ${width * height}. Swift wraps every interpolation in \( ) regardless of complexity.

The method names differ (count → length, uppercased() → toUpperCase()), and Dart’s split takes a plain string or pattern rather than a Character separator. Note length counts UTF-16 code units, unlike Swift’s grapheme-cluster count.

Dart’s multiline literal uses triple quotes (single or double), and its raw string prefix is a lowercase r rather than Swift’s #"…"# delimiters. In a raw string, backslashes are literal in both languages.

Both keep int and double distinct and refuse to mix them implicitly. Dart adds a shared supertype num that either can flow into, whereas Swift has no common numeric supertype — you convert explicitly with Int( ) / toInt().

This is a genuine trap: in Dart / always produces a double, even for two ints, so 7 / 2 is 3.5. Truncating integer division has its own operator, ~/. In Swift, Int / Int stays an Int.

Dart numbers carry many helpers as methods and getters: abs() and round() are methods, and isEven/isOdd are properties rather than the method call Swift uses. But max is a free function in dart:math, not a method — unlike Swift’s global max(_:_:). Note (-4).abs() needs the parentheses so the minus binds to the literal.

Dart’s List replaces Swift’s Array, but two things bite: List is a reference type (a final list is still add-able), and map returns a lazy Iterable that you must finish with .toList(). Swift’s map returns an Array directly.

The literal syntax is nearly identical. The catch: indexing a Dart Map returns a nullable value (V?), so ages["Ada"] has type int? — the compiler forces you to handle the missing-key case, much as Swift’s dictionary subscript returns an Optional.

A brace literal with no colons is a Set in Dart, just as {} with colons is a Map. Beware the empty case: {} is an empty Map, so an empty set needs an explicit <int>{} type argument.

Dart builds collections declaratively with the spread operator ..., the if-element, and the for-element right inside the literal. There is no Swift equivalent — you would append imperatively or chain map/filter. This shines in Flutter widget lists.

This is the single most important difference. Dart has no value types: a class instance is always a reference, so second = first aliases the same object and the mutation is visible through both. The Swift struct copies. Reach for records or immutable classes when you want value semantics.

Dart records (3.0) are the value types the language otherwise lacks: they compare by structure, copy by value, and destructure like a Swift tuple. Named fields are accessed by name (point.x); positional fields by $1, $2. They are the idiomatic way to return multiple values.

Because a class cannot copy itself, the community convention is a hand-written (or generated) copyWith that returns a new instance with some fields replaced — exactly the mutate-a-copy that Swift gets for free from var updated = base. Flutter code is full of these.

Dart uses the C-style three-clause for and requires parentheses around every condition. There is no Swift range operator; iterate with for (final x in iterable) or a counting loop. Note the braces are mandatory even for a single statement in idiomatic Dart.

Dart’s indexed getter pairs each element with its position as a record, which the for loop destructures — the direct counterpart to Swift’s enumerated(). Before records existed, Dart code used asMap().entries for this.

The ternary is identical, but the cascade (..) is pure Dart: it calls a sequence of methods on the same object and evaluates to that object, so you configure a value without naming it repeatedly. Swift has nothing like it.

Dart writes the return type first and the parameter types before their names. The => arrow body is Dart’s shorthand for a function whose whole body is one expression — the analog of Swift’s implicit single-expression return.

Dart named parameters go inside { } and are optional by default — the opposite of Swift, where every argument label is required unless you write _. Mark a named parameter required to force it, and give a default to make it truly optional.

Dart closures always list their parameters explicitly — (value) => … — with no $0 shorthand and no trailing-closure sugar, so the function goes inside the parentheses. Also note filter is named where, and it returns a lazy Iterable.

A function type is written ReturnType Function(ArgTypes) in Dart, versus Swift’s (ArgTypes) -> ReturnType. Otherwise functions are first-class in both — assignable, passable, and returnable.

Dart’s this.name parameter assigns the field directly, collapsing Swift’s init boilerplate. The constructor is named after the class, and there is no self/init keyword pair — just ClassName(...).

Dart supports multiple named constructors (Point.origin()) as a first-class feature, using an initializer list after the colon to set final fields. Swift achieves the same with additional inits or static factory methods.

Dart spells a computed property as a get (and optionally set) member, where Swift uses a braces block with an implicit getter. Both are accessed like a stored field, with no call parentheses.

Dart uses extends (not :) for the superclass and an @override annotation that is advisory rather than required — unlike Swift’s mandatory override keyword. super works the same in both.

Dart’s enhanced enums (2.17+) carry fields and a const constructor, which is how you attach a payload like Swift’s raw value — but there is no built-in rawValue, so you declare the field (code) yourself. Each case calls the constructor.

Both languages let an enum declare methods and computed properties. Dart separates the case list from members with a semicolon, and a switch over an enum is exhaustive in both — the compiler flags a missing case.

This is the enum false friend. A Swift enum with associated values is not a Dart enum — Dart enum cases cannot carry per-case data. Model it as a sealed class hierarchy; the switch over the sealed type is still exhaustive, and object patterns (Circle(:final radius)) bind the fields.

Dart 3.0’s switch expression returns a value with => arms and uses _ as the wildcard. Relational and logical patterns (>= 1 && <= 9) replace Swift’s range case 1...9. Both are exhaustive and both are expressions.

Record patterns destructure positionally just like Swift tuple patterns, binding with final x where Swift writes let x. A constant in a position (0) constrains the match. This is the feature that makes Dart 3 feel closest to Swift.

Dart’s if (value case Pattern) is the direct analog of Swift’s if case Pattern = value — a single-branch match that binds variables into the if body. The keyword order flips, but the behavior is the same.

Dart has no protocol keyword; instead every class defines an implicit interface, and you use implements to conform to one. An abstract interface class declares a contract with no implementation — the closest match to a Swift protocol.

A Dart mixin supplies shared implementation to any class that uses with — the role Swift fills with a protocol extension that provides default methods. Unlike a protocol extension, a mixin can also declare state and can be constrained with on to require a superclass.

Both languages add members to existing types without subclassing. Dart’s extension is named (IntExtras) and declares its receiver with on int, referring to the value as this rather than Swift’s self. The name lets you hide or resolve conflicting extensions.

Generic syntax matches closely: a type parameter in angle brackets, used as a normal type. The declaration order differs because Dart puts the return type first (T? firstOrNull<T>(...)).

Dart bounds a type parameter with extends where Swift uses :. A subtle difference from Swift generics: Dart generics are reified — the type argument survives to run time, so items is List<int> actually works, unlike on the JVM.

Generic classes work the same way in both languages. Note Dart infers the type argument of Box(21) from the constructor argument, just as Swift infers Box(value: 21) — no explicit <int> needed.

The big shift: Dart exceptions are unchecked. A method that throws carries no throws in its signature and callers are never forced to handle it — nothing like Swift’s try at every call site. You can throw any object, though implementing Exception is the convention.

Dart selects a handler by type with on TypeName, and a bare catch (error) takes anything — versus Swift’s catch Pattern. Dart’s finally is the counterpart to Swift’s defer, though defer is scoped to the enclosing function rather than a try block.

An async Dart function returns a Future<T> — the concrete type Swift keeps implicit behind async. You await a Future just as in Swift, and main itself can be async.

Where Swift kicks off concurrent work with async let, Dart collects a list of Futures and awaits them together with Future.wait, which resolves to a list of results. Both let independent async work overlap rather than run in series.

Dart’s Stream is the analog of Swift’s AsyncSequence, and an async* generator with yield is far terser to write than building an AsyncStream by hand. You consume it with await for, mirroring Swift’s for await.

Dart’s concurrency model is fundamentally different: there is no shared mutable memory. An Isolate has its own heap, and you communicate by copying messages, so data races are impossible by construction — a stronger guarantee than Swift’s actor, which shares memory but serializes access. Most Dart code stays on one isolate’s event loop and only spawns one for heavy CPU work.