C++.CodeCompared.To/Swift

A Swift file at top level executes its statements in order, so main is synthesized rather than written. The standard library is implicitly available, so there is nothing to import for ordinary work — import Foundation is only needed for the older Objective-C-derived layer. print appends a newline and renders any type through its CustomStringConvertible conformance, so there is no stream-operator chain and no format string to mismatch.

The manifest, Package.swift, is written in Swift itself, so there is no build DSL to learn. What is genuinely different from Go and Rust is governance: Swift has one implementation and Apple sets the roadmap, so a feature you need arrives when Apple ships it. Linux and Windows support are real and used in production, but Apple platforms get the tooling, the debugger integration and the frameworks first. That is the strategic consideration to weigh, quite apart from anything about the language.

A struct is a value type — it copies on assignment, cannot be nil, and gets a memberwise initializer for free. A class is a reference type, heap-allocated and reference-counted. So the C++ column prints 1 1 and the Swift column prints 1 99. What differs from C# is the default: Swift's standard library is built on structs — Array, String, Dictionary and every numeric type are all value types — and the guidance is to reach for struct first and class only when you need identity or inheritance. The next row is why that is affordable.

Every value type with heap storage — Array, String, Dictionary, Set — shares its buffer on copy and duplicates only on the first write, using the reference count to detect uniqueness. So passing an array by value costs a retain, not a memcpy, and you never write const& to avoid a copy that is not happening. The consequences are worth internalizing: the copy cost moves from where you can see it (the call) to where you cannot (a mutation), and a value type behaves as if it were deeply copied, so there is no aliasing to reason about at all.

C++ makes you write const on the methods that do not mutate, which is a discipline that erodes the moment one function forgets. Swift makes you write mutating on the ones that do, so the annotated case is the rarer one and therefore actually gets written and noticed — the same inversion Rust made with mut. Enforcement comes from the binding rather than the reference: a let value type cannot have a mutating method called on it at all. Note also the argument label by:, which is part of the method's name — increment(by:) — and is why Swift call sites read the way they do.

The compiler inserts the retain and release calls, so you never write them, and deinit runs at a predictable point when the last reference goes away. That is a meaningfully different bargain from C# or Go: no collector, no pause, and a destructor you can rely on for closing files and sockets. The costs are the ones shared_ptr has too — an atomic refcount operation on every copy, which shows up in hot loops — plus the one in the next row, which C++ has as well and Swift cannot solve either.

The correspondence is direct: weak is std::weak_ptr, and Swift adds unowned, which is a non-optional non-owning reference that traps if the target is gone rather than being checkable. Use weak when the target may legitimately outlive nothing, and unowned when the reference logically cannot outlive its target — a child pointing at a parent that owns it. The place this bites in practice is closures, which capture strongly by default: a closure stored on an object that captures self creates exactly this cycle, and [weak self] in the capture list is the fix.

if let binds the unwrapped value only inside the branch, so there is no operator* to call on an empty optional — the undefined behavior C++ permits is not expressible. ?? is value_or, and ?. chains through nil. The construct worth stealing conceptually is guard let, which handles the failure case and exits, leaving the unwrapped value bound in the enclosing scope — so a function reads as a list of preconditions followed by the happy path, rather than as ever-deepening nesting. Force-unwrapping with ! exists and traps rather than being undefined.

An extension can add methods, computed properties, initializers and protocol conformances to any type, including one from another module — so the standard library's own types gain your vocabulary without wrappers or adapters. The conditional form (where Element: Numeric) is the part with real power: it adds methods only to the instantiations that qualify, which is what C++ needs partial specialization or a constrained free function template for. What extensions cannot do is add stored properties, since that would change the type's layout.

willSet and didSet attach code to an ordinary stored property, so no accessor pair is needed to observe a change — which is why Swift code rarely has hand-written setters at all. A computed property (area) is a method that reads as a field and can be read-write with an explicit get/set. The knock-on effect for a C++ programmer is that the convention of writing getters and setters up front, purely to preserve the option of changing the implementation later, is simply unnecessary here.

The half that survives from inheritance is shared behavior, via protocol extensions with default implementations; the half that does not is shared state, since a protocol declares no storage. What is genuinely beyond C++ is retroactive conformance — extension Int: Shape makes an existing type satisfy a protocol declared elsewhere, which is Rust's orphan-rule-bounded trait impls and has no C++ counterpart. Note any Shape: Swift now requires the any keyword to mark an existential (a runtime-dispatched box), so the cost of dynamic dispatch is visible at the use site rather than implied.

some Shape is an opaque type: one concrete type known at compile time, specialized and statically dispatched — the template. any Shape is an existential: a box that can hold any conforming value, dispatched through a witness table and possibly heap-allocated if the value is large — the base-class pointer. Swift made any mandatory in version 6 precisely so this cost stops being invisible, which is a deliberate correction of an earlier design where a bare protocol name meant the expensive one. The rule of thumb is some unless you genuinely need a heterogeneous collection.

The body may only use what Comparable guarantees, so a mistake is reported at the definition rather than unrolling into the standard library at the call. Implementation is a hybrid: the compiler emits one generic version using witness tables, and specializes hot instantiations like a template when it can see across the module boundary — which is why @inlinable exists. What C++ keeps that Swift gives up is the metaprogramming: no specialization you control, no non-type parameters until recently, and nothing resembling a compile-time computation language. Note for … where, which folds the filter into the loop.

The conforming type supplies the concrete type, usually inferred from the implementation, and callers reach it as C.Item. This is close to a C++ concept requiring a nested typedef, with the difference that the relationship is declared and checked. The wrinkle worth knowing is that a protocol with associated types could not be used as an existential at all until Swift 5.7 — the notorious "protocol can only be used as a generic constraint" error — and any Container now works through primary associated types and type erasure.

Everything std::variant does, this does with less ceremony: no std::visit, no if constexpr ladder, no std::get that throws, no valueless-by-exception state. The cases are named, so an enum with two Double payloads meaning different things is expressible where std::variant<double, double> is useless. And the switch must be exhaustive, so adding a case turns every incomplete match into a compile error — the check -Wswitch abandons the moment a default: appears. Enums can also have methods, computed properties and protocol conformances.

A case can destructure and bind (case let (row, column)), filter with where, and match a range (80..<90) — which C++ needs an if/else ladder for even after structured bindings. The same patterns work in if case, guard case and for case, so the syntax pays for itself across the language rather than only inside a switch. Two details for a C++ reader: switch never falls through (there is a fallthrough keyword for the rare case), and it must be exhaustive, so default is required whenever the compiler cannot prove coverage.

A function that can fail must be marked throws, and every call to it must be marked try — so unlike C++, where any call may unwind invisibly, every possible early exit is visible in the source. Swift 6's typed throws (throws(PortError)) go further and let the compiler check a catch for exhaustiveness, which is closer to Rust's Result than to an exception. Under the hood there is no stack unwinding: errors are returned in a register, so the cost is a branch. try? converts a failure to nil and try! traps, which are the two escape hatches.

Unlike Go's, Swift's defer is scoped to the enclosing block rather than the function, and deferred blocks run in reverse order on any exit — return, thrown error, or leaving a loop body. Note what Swift keeps that Go and Zig do not: a class has deinit, which is a genuine destructor running deterministically under ARC, so a type can guarantee its own cleanup for its users. So the choice is the C++ one — put it in the type when several callers need it, use defer for one-off local cleanup — rather than a workaround for a missing feature.

A Character is an extended grapheme cluster — what a human calls one character even when it is several code points, like an emoji with a skin-tone modifier — so count is the answer a user would give and comparison handles canonical equivalence correctly. The price is that greeting[2] does not compile: locating the nth cluster requires walking from the start, and Swift refuses to hide an O(n) operation behind subscript syntax. That honesty is the single most-complained-about thing in the language, and it is also why Swift string handling is correct where std::string's is merely fast.

A ~Copyable type has no copy at all, and the compiler tracks its single owner — so using a value after it has been consumed is a compile error, not a legal read of an unspecified state. That is the guarantee C++ cannot make: a moved-from object is "valid but unspecified", and you must remember to write a move constructor that leaves it in a sensible one. The parameter modifiers spell the rest: consuming takes ownership, borrowing is const&, and inout is a mutable reference. If this sounds like Rust, it is — Swift adopted the useful half without the lifetime annotations. A ~Copyable struct may also have a deinit, which an ordinary struct cannot; it is left out of the example above deliberately, because the exact point at which a consumed value is destroyed changed between Swift 6.2 and 6.3 — so a row whose output depended on destruction timing would report one thing under one toolchain and another under the next.

A task group cannot return until its children finish, so a task cannot be leaked, orphaned, or forgotten — and cancellation propagates down the tree automatically. Compare std::async, where the future's destructor blocking is a notorious surprise and nothing relates one task to another. await marks every suspension point, so you can see exactly where other work may interleave. The reason this matters beyond ergonomics is the next row: knowing the task tree is what lets the compiler check for data races.

An actor is a reference type whose mutable state is isolated: calls from outside are serialized and must be awaited, so the association between lock and data is enforced by the type rather than remembered. The wider mechanism is Sendable — a marker for types safe to cross an isolation boundary, checked by the compiler — which is Swift's equivalent of Send/Sync. The honest caveat is that this is much newer than Rust's: strict concurrency checking became the default only in Swift 6, and migrating an existing codebase to it is real work that the community is still in the middle of.

Swift 5.9 shipped bidirectional C++ interoperability: Swift imports C++ classes, methods, templates and operators from a header with no shim and no generated bindings, and C++ can call Swift back through a generated header. That is a different position from every other language on this anchor — Rust, Go and C# all meet C++ across a C-shaped boundary. The limits are real: std::vector and std::string map well, ownership must still be reasoned about by hand across the line, and virtual inheritance and exceptions are partly supported. But "call your existing C++ from a new component" is now a genuine option rather than a project.

Technically Swift is a strong package: value semantics remove aliasing bugs, optionals remove null dereferences, ~Copyable removes use-after-move, and Swift 6 removes data races — a safety story close to Rust's with a much gentler learning curve, and deterministic cleanup that neither Go nor C# offers. The constraint is reach. One vendor sets the roadmap, Linux and Windows support trails, and the ecosystem outside Apple's frameworks is thin compared with what a C++ project can draw on. If you ship on Apple platforms, the C++ interop makes incremental adoption genuinely practical and Swift is the obvious choice. If you do not, Rust answers most of the same problems with broader reach.