Swift.CodeCompared.To/Scala

Scala 2 has no top-level definitions, so the entry point lives in an object — a singleton, which is Swift's static members with a name you can pass around. func is def, Void is Unit, and semicolons are optional. Scala 3 adds top-level definitions and an @main annotation, which collapses this to almost exactly the Swift form.

Immutable by default in both, with the same two keywords — let is simply spelled val. Two small upgrades: lazy val is a language keyword rather than Swift's lazy var-with-a-closure (and it is memoized and thread-safe), and string interpolators are extensible — s"…" is a method call on StringContext, so a library can add sql"…" or json"…" that validate at compile time. Swift has no equivalent.

The f interpolator is the one worth knowing: f"${12.5}%.2f" is checked at compile time, so a %d against a String will not build — where Swift's String(format:) is a run-time call that will happily print garbage. Scala's triple-quoted string does not strip indentation on its own, which is why .stripMargin and the | markers are there; Swift measures the indentation of the closing delimiter instead. And because an interpolator is just a method on StringContext, a library can add its own — sql"…" and json"…" are real and have no Swift counterpart.

Swift has one expression form of this — the ternary — and Scala needs none because the ordinary if already is one. The same holds for match, which is where it pays off: a Swift switch assigning to a variable declared just above it becomes a val x = value match { … } with no mutable step in between. Scala 3 also made then and the parentheses optional, which is why the two branches read as one expression rather than as a block of statements.

Both languages solve the same problem; Swift puts absence in the syntax and Scala puts it in a value. Because Option is an ordinary type, the operators become methods — map for ?., getOrElse for ??, get for !, foreach for if let — and it composes with everything else: it goes in a List, it is pattern-matched, it flows through a for-comprehension, and the same map/flatMap vocabulary works on List, Either, Try and Future. The cost is an allocation per Some (Swift's ? is erased and free), and the fact that null still exists underneath on the JVM — idiomatic Scala wraps it immediately with Option(javaValue).

The rule that makes the rest obvious: map when the function cannot fail, flatMap when it can — otherwise you get an Option[Option[Int]], which is exactly what Swift's ?. flattens for you silently. What Scala gains by having no syntax is that everything Option can do, List, Either, Try and Future can do with the same names; ?. works on optionals and on nothing else. fold, filter, exists and collect are all available on an Option and have no Swift equivalent at all.

This is the payoff for Option being a type rather than syntax. List[Option[A]] flattens to List[A] because an Option is implicitly viewable as an Iterable — so flatten, flatMap and a for comprehension all work on it without anybody having written a special case. The output differs in one place worth noticing: Scala prints List(1, 3) and Swift prints [1, 3], which is the collection's own description rather than anything about the operation.

A case class gives you what a Swift struct gives you — generated equality, a readable toString, and (better than Swift) a copy(field = value) expression and destructuring via unapply. The caveat is that it is a reference type: val alias = ada shares the object rather than copying it. That is safe in practice because case-class fields are val by default, so immutability does the job value semantics do in Swift — but the moment you write var in a case class, you have a shared mutable object and Swift's guarantee is gone. The Scala convention is exactly the Swift habit: keep them immutable.

Because nothing was copied, nothing had to be: first and second are one immutable object, and copy(x = 99) allocates the only new one in the example. That is the same optimization Swift's copy-on-write performs for Array, arrived at from the other direction — Scala makes the value immutable so sharing is always safe, where Swift copies eagerly and defers the work. 🚨 A case class with a var field is legal and throws all of this away: == keeps comparing by value while the value can change underneath, so it will not behave in a Set or as a Map key.

The distinction is worth holding onto because the two languages put it in different places. Swift puts it on the binding — one Array type, mutable or not depending on let versus var. Scala puts it on the type — List has no append to call, so a value of that type is safe to share with anything, including another thread, no matter who holds the binding. That is why val on a mutable map still lets you change the map: the binding is fixed and the object is not.

These are the same declaration in two languages: a case with a payload becomes a case with parameters, a case without one stays a bare name, and match destructures exactly as switch does. The only syntactic tax is import Shape.* — Scala scopes the cases inside the enum, so a match either imports them or writes Shape.Circle each time, where Swift lets you lead with a bare dot. One real difference remains, and it is a downgrade: an inexhaustive match is a warning in Scala, not an error, so it compiles and throws MatchError at run time. Every serious Scala build turns on -Xfatal-warnings, which restores the guarantee you take for granted.

Scala's values is allCases, ordinal is the position with no Swift equivalent, and Direction.valueOf("North") is Direction(rawValue:). The difference underneath is that a Scala 3 enum is sugar for a sealed hierarchy of objects, so each case is a real singleton you can pattern-match on, extend with a trait, and hold in a Map — while a Swift enum without associated values is fundamentally an integer with names. That is also why Scala's cases are capitalized: they are types.

Any object with unapply(input): Option[Result] can appear on the left of a case, which makes pattern matching open: you can match on a parsed integer, a regex capture, a JSON shape, or a domain concept like case ValidEmail(user, host), and it reads as though the language knew about it. Swift's switch is closed by comparison — it matches types, constants and conditions, so real parsing must be lifted out into a variable first, exactly as the left column does. Scala also has the cons pattern (head :: tail), which makes recursive list code read the way the textbooks draw it.

🚨 Both of these are unsound in the same way, and for different reasons. Swift's default is required because Any is open; Scala's case _ is required for the same reason, and worse, case list: List[Int] would match a List[String] too — the element type is erased at run time and the compiler warns about exactly that. Where Scala pulls ahead is that a match arm is not limited to types: case Point(0, y), case head :: tail, case n if n % 3 == 0 and a user-defined extractor all sit in the same list of arms.

The @ earns its keep in a nested match, where the piece you want to keep is three levels down and reassembling it means writing the constructor call out again — which then has to be kept in step with the pattern above it. Scala also matches lists structurally (case first :: second :: rest) and can bind a name inside that, which is where Swift's array patterns stop entirely: there is no case [first, second, ...rest].

A trait is a protocol with two additions. It can hold state (var greetings), which a Swift protocol extension cannot — Swift protocols may declare a property but never store it. And super inside a trait is resolved at mix-in time, by linearizing the traits right to left, so with Loud with Counting makes each trait a composable decorator over the next. That is the "stackable traits" pattern, it has no Swift equivalent, and it is also the sharpest edge in the language: reorder the with clauses and the behavior changes silently.

The two columns print the same line and get there differently: Swift nests three objects by hand, Scala names three traits and the compiler builds the chain. The rule is that with reads right to left — the last trait named runs first and its super is the one before it — which is unintuitive exactly once and then never again. What you are buying is that the pieces need not know about each other; the cost is that a super call whose target is decided by the mixin order at every use site is genuinely harder to follow than a constructor argument you can see.

The visible difference is what happens when you put one in a collection. A Swift protocol with an associatedtype could not be used as a type at all until any Container arrived, and even now the associated type is hidden behind it. Scala has no such rule, because a trait is a type from the start. Scala also offers the other spelling — trait Container[Item], a type parameter rather than a member — and the choice is real: a parameter can vary per use site, a member is fixed by the implementation, which is exactly what associatedtype is.

One given at the top, and every call below it that needs a Configuration gets one — including calls three layers down, which is where the hand-threading in the left column becomes genuinely painful (add a parameter to a leaf function and every caller changes). Notice that process writes (using Configuration) with no name at all: it never reads the value, it only has to be eligible to hand it on. This is how Scala passes an ExecutionContext to every Future, a transaction to every query, and a logger to everything. The cost is the one everybody warns you about — when no value is found, the error says one is missing but not why the candidate you expected was ineligible. The two keywords exist to make that answerable: older Scala spelled both halves implicit, and separating given for the supply from using for the demand is what lets the compiler say which half it could not satisfy.

Both columns work, and this is the closest Swift gets to a type class — retroactive and conditional conformance is genuinely rare and genuinely good. The difference is where the behavior lives. Swift attaches it to the type (an Int is now, everywhere in the program, a JsonWritable), so there can be exactly one conformance and a conflict between two libraries is unresolvable. Scala keeps it in a separate value — the given JsonWriter[Int] — which the compiler assembles per call site — so you can have two different encodings in scope in different files, swap one for testing, or pass one explicitly. That indirection is why every Scala JSON, ordering, and equality library is built this way, and it is the price of admission for the higher-kinded abstractions in the next section.

The one difference that matters is scope. A Swift extension on Int is visible to everything that imports the module — there is no way to add a method for one file only. A Scala extension is an ordinary definition you have to bring into scope, so two libraries can each add a squared to Int and nothing collides until a file imports both. That also makes the failure mode different: Swift tells you at the definition, Scala at the call site, with an ambiguity error naming both candidates.

A Swift generic parameter always stands for a complete type, so F<_> is simply not writable and there is no way to say "any container that can be mapped over" — you write doubleArray, doubleOptional, doubleResult, and accept the duplication. (Swift's some Collection and its associated types get you partway for consuming a container, but never for returning the same shape.) In Scala, F[_] plus implicits is the foundation everything functional is built on: Functor, Monad and Traverse in Cats are exactly this trait with more laws, which is what lets one traverse work over every effect type in a program.

The check is the point. Writing +Element on a box with a def put(item: Element) is rejected at the declaration, because that is the combination that lets you store a cat in a list of dogs — the hole Java left open in its arrays and pays for with a run-time ArrayStoreException. Scala's answer is to make you declare the intent and then prove it; Swift's is to hard-code the safe answer for the standard library and forbid the question everywhere else. -Element, contravariance, is the other direction and is what makes Function1[-In, +Out] substitutable the way intuition says it should be.

Swift's guard let … , let … , let … else handles the optional case well, and that is where it stops: the shape cannot be reused for a chain of Results, a list comprehension, or a sequence of futures. Scala's for is sugar for flatMap, so the same three lines work over Option (short-circuit on None), Either (short-circuit on Left, carrying a typed reason out), List (a nested loop), Try, Future, or any type you give a flatMap to. That is the whole argument for the abstraction, and it is why fragmented per-container idioms are the concrete cost of not having it.

The yield is the whole difference. Without it a Scala for is a statement run for its effects, the same as Swift's; with it the loop is an expression that builds a value, and the nesting turns into a flatMap chain the compiler writes for you. Because the rewriting is purely syntactic, the same shape works over Option, Either, Try and Future — anything with flatMap and map — which is why one construct covers both "iterate over two lists" and "do four things that might each fail".

The operators line up (first(where:) is find, .lazy is .view), and _ is $0 — with the catch that each _ refers to a different parameter, so list.reduce(_ + _) means (a, b) => a + b and you cannot use _ twice for the same value. The genuinely new tool is collect, which takes a block of case clauses (a partial function) and keeps only the elements that match — a filter, a map, and a destructuring in one. Note also that Scala's List is persistent: adding an element returns a new list sharing its tail, which is how immutability stays cheap.

The names to carry over: reduce with a seed is foldLeft, Dictionary(grouping:) is groupBy, allSatisfy is forall, contains(where:) is exists, enumerated() is zipWithIndex, and joined(separator:) is mkString. The ones with no Swift counterpart are worth knowing about before you write them yourself: sliding and grouped for windows, span and partition for splitting on a predicate, groupMapReduce for the group-then-aggregate that otherwise takes three passes, and view for making the whole chain lazy.

Scala has exceptions and they are unchecked, so throws disappears from the signature — the information Swift puts in the type system is gone unless you put it back yourself, which is exactly what Either[Error, Value] does. The advantage over throws is that a failure is a value: it can be stored, mapped, collected into a list, and chained in a for-comprehension, none of which a thrown Swift error can do. Try is try? with the error preserved (and it pattern-matches, since Success/Failure are ordinary case classes), and catch takes a block of case clauses, so the full pattern language applies to exceptions too.

The shapes differ in where the cleanup is written relative to what it protects. Swift's defer sits next to the acquisition, so the two lines are adjacent and the scope decides when it runs; Scala's finally sits at the far end of the block, which is worse for reading and better for one thing — try is an expression, so val answer = try … finally … is a value and there is no mutable variable to declare first. Using(resource) { … } is the form to reach for with a real file or socket: it closes in reverse order, suppresses a secondary failure into the primary one, and returns Try.

Three assumptions break. A Future is eager: constructing it submits the work, so there is no async { } to write and no way to describe a computation without starting it. Nothing owns it — there is no task group, no structured concurrency, and no cancellation (you can ignore the result; the work runs on). And the thread pool arrives as an implicit ExecutionContext, which is why that odd import …Implicits.global appears in every tutorial. The compensation: a Future is an ordinary monad, so it composes with map, flatMap and the for-comprehension you already know — but read that last block carefully, because a for over futures constructed inside it runs them sequentially, which is the most common performance bug in Scala. On memory: the JVM has a tracing GC, so there is no ARC, no deinit, no weak, and cycles are collected for free.

🚨 The trap is that the for reads sequentially and is not: the two fetch calls started before it, so it only joins them. Writing for a <- fetch(1); b <- fetch(2) instead runs them one after the other, because the second call does not happen until the first completes — the same source shape, half the speed, and nothing warns you. Swift makes the distinction visible in the syntax: async let starts eagerly, a bare await does not. The other half of the difference is that Future needs an ExecutionContext in scope and has no cancellation at all, where Swift's task tree carries both.