C.CodeCompared.To/Swift

print appends the newline and knows how to render whatever it is given, so it is closer to puts than to printf; print(x, terminator: "") is the no-newline form. There is no return 0 because there is no function to return from — falling off the end of the file is a zero exit status, and exit(3) from the platform module is how you return something else.

The precision is the one thing interpolation does not carry: String(format:) from Foundation takes C’s conversion specifiers when you want them, and formatted() or explicit rounding covers the rest. What has gone is the mismatch — printf("%s", 42) compiles under most settings and prints whatever lives at address 42, while there is no way to spell that here.

That is the actual C fputs and the actual C stderr, called with no wrapper — which is the whole point of this page in miniature. Foundation offers FileHandle.standardError if you would rather not import the platform module, and it is what an application would use; the direct call is here because it shows how thin the boundary is.

Element zero is the program name, matching argv[0], which is why both columns skip it. CommandLine.unsafeArgv is still there if you need the original char ** — for instance to hand straight to a C library — and its name tells you exactly what you are taking on.

Inference runs only from the initializer, so this is nothing like a dynamic language — the type is fixed at compile time and count = "text" is an error. Where there is no initializer you say the type: var total: Int. The compiler also warns when a var is never reassigned, which is how let ends up almost everywhere.

The trap is a deliberate choice: a program that has overflowed is already wrong, and stopping is better than continuing with a wrong number. &+, &- and &* are the wrapping operators for when the wrap is the point — a hash function, a checksum — and the …ReportingOverflow family is the version that hands you a flag instead. None of these is undefined; every one of them has a specified answer.

The verbosity is real and it is the whole trade: every conversion is visible at the place it happens, so the C column’s last line — where -1 becomes a very large unsigned value and the comparison comes out false — cannot be written. The exactly: initializers are the safer constructors: each returns an optional and gives nil rather than truncating, which is the check C makes you write by hand — Int8(exactly: 300) is nil, where a C assignment would quietly store 44.

MemoryLayout<T>.size is sizeof, and it has two siblings C conflates into one number: stride is the distance between consecutive elements in an array — which is size rounded up to the alignment, and is what sizeof actually gives you — and alignment is the requirement itself. When allocating a buffer for a C API, stride is the one you want.

An optional is not a pointer with a flag — it is an enumeration with two cases, some(Wrapped) and none, so Int? works exactly as well as String? and there is no sentinel value to reserve. The consequence is that the null check is not something you can forget: reaching the value requires unwrapping, and the compiler knows whether you did.

guard let is the one worth adopting first: it binds for the rest of the enclosing scope rather than for a nested block, so the happy path stays un-indented and the early return is where the failure is handled — which is the shape the C column’s if (x == NULL) return ladder is reaching for. The trailing ! is the deliberate escape: it traps at run time if the value is nil, so it is a promise you are making, and every style guide treats it as something to justify.

The C column’s last two lines print the same thing for a failure and for a legitimate -1, which is the bug the sentinel convention guarantees eventually. Int("…") returning Int? is the standard library making the same choice everywhere: Array.first, Dictionary subscripting, and firstIndex(of:) all hand back optionals rather than reserving a value.

The deinit runs at a known moment, which is why it is a workable place to close a file handle in a way a garbage-collected finalizer is not. What reference counting cannot free on its own is a cycle — two objects holding each other stay alive forever — so Swift gives you weak and unowned references to break one, and that is the leak you will actually hunt. Structs, being value types, are not reference counted at all.

Deferred blocks run in reverse order of registration, so the second buffer is released before the first — which is the order the goto cleanup ladder achieves by listing the frees backwards. The real advantage is proximity: the release sits on the line after the acquisition, so a new return added later cannot skip it, and neither can a thrown error.

Every standard-library collection works this way — Array, String, Dictionary, Set — so passing a large array to a function that only reads it costs a retain, not a copy. The consequence for a C programmer to internalize: there is no aliasing between two array variables, ever, so the whole family of "somebody else mutated my buffer" bugs is gone, and the cost model still matches your instincts.

An array does not decay: pass it anywhere and it is still an array, still knows its count, still bounds-checks. The C column’s last line — the caller passing a length the callee has no way to question — has no spelling here. If you genuinely want the pointer-and-count shape, withUnsafeBufferPointer in the unsafe section hands it to you for the duration of a closure.

The trap costs a compare and a branch per subscript, and the optimizer removes most of them — a for value in numbers loop is proved safe and emits no check at all. Note what the standard library does instead of trapping where absence is legitimate: first and last return optionals, so an empty array gives nil rather than reading whatever was at index zero.

The index behavior is the thing to remember: middle[0] traps, because the slice’s valid indices start at 2. That is deliberate — it means an index found in a slice is meaningful in the parent array — and it is why Array(slice) exists for when you want a fresh, zero-based copy. The same idea appears as Substring for strings, and for the same reason.

$0 is the first closure argument when you have not named it, which keeps short transformations short. These are eager — each one walks the array and builds a new one — so a three-stage chain over a million elements does three passes; numbers.lazy.filter { … }.map { … } switches to a single fused pass, at the cost of a little indirection per element.

The emoji is one character, three Unicode scalars, and eleven UTF-8 bytes — and the C column can only report the last of those. That correctness has a price: count is O(n) because grapheme boundaries must be found, and a String cannot be subscripted by an integer at all. String.Index is what you use instead, which is the single biggest adjustment coming from a language where a string is an array.

The practical upshot at an interop boundary: a Swift string can hold something a C function will silently truncate. withCString and the automatic conversion when calling a C function both produce a NUL-terminated copy, so an embedded zero means the C side sees a shorter string than you sent — worth remembering before passing user input through to a C library.

dropFirst and prefix return Substrings, which share the original’s storage — cheap, and the reason a long-lived substring keeps the whole original string alive until you build a fresh String from it. uppercased is locale-correct rather than the ASCII arithmetic the C column would need, which is most of why C string handling looks simpler than it is.

The automatic conversion is real but temporary: the buffer is valid only for the duration of that one call, so storing the pointer that strdup was invented to avoid needing is still exactly as wrong here as in C. withCString makes the window explicit — the pointer is valid inside the closure and nowhere else — which is Swift’s general pattern for handing out an address it does not want you to keep.

Note that the struct version needs var copy = copy before it can write at all: function parameters are constants in Swift, which is a stronger position than C’s "the copy is yours to scribble on". Note too that asClass is declared let and its field still changed — let on a class reference means the reference cannot be repointed, not that the object cannot be modified, which is exactly C’s Counter *const.

The mutating marker is not decoration: a let struct will not let you call one, so the compiler enforces the const discipline the C column can only ask for. The memberwise initializer Rectangle(width:height:) comes free with the struct — there is no boilerplate constructor to write, and the argument labels make the call site read.

A type that says : Shape and omits area fails to compile, which is the check the C column cannot make — nothing stops you leaving a function pointer null. Both shapes fitting in one array is the other half, and it costs something: a [Shape] stores each value in an existential box with a witness table, which is one indirection per element. Making the function generic over <T: Shape> instead specializes it and removes the box.

The tag and the payload cannot get out of step, because they are the same thing — and the switch must handle every case or the file does not compile, so adding a fourth case surfaces every place that needs updating. The runtime layout is still a tag plus a union, often packed into the spare bits of the payload, so the representation is as tight as the C one and none of the hazards come with it.

An extension cannot add stored properties — it would change the layout — so it is methods and computed properties only, which keeps the size of every existing value unchanged. This is how the standard library is organized internally, and it is also how protocol conformance is usually added: extension MyType: Equatable { … } keeps the conformance and its methods together rather than swelling the original declaration.

The labels are part of the identity, so copy(from:start:count:) and copy(from:to:) are different functions rather than overloads — which is also how Swift avoids most of the overload ambiguity other languages have. The underscore is the deliberate opt-out, used where the parameter’s role is obvious from the function name, as in print(_:).

The & is required, which is the opposite of C++ and Pascal and means a call site never hides a mutation. Under the hood this is copy-in, copy-out rather than a genuine reference, so passing the same variable as two inout arguments is a compile error rather than the aliasing surprise it would be in C. There is no way to store an inout parameter for later — the window closes when the function returns.

The captured variable is not copied — the closure holds the same storage, which is why total ends at 10 and why factor outlives the call to multiplier. That last part is the piece C cannot do: a function pointer can only point at code the compiler emitted, so the closest C gets is a struct holding a pointer and its data, which is what the void * in the left column is. A closure that captures nothing is convertible to a real C function pointer, which the interop section uses.

The leading count is gone because the array knows its length, and every element is type-checked at the call site — sumOf(1, "two") does not compile, where sum_of(2, 1, "two") does and then reads a pointer as an int. Default values are evaluated at the call, in the caller’s context, so func log(at time: Date = Date()) gets the current time on each call rather than the one from when the program started.

Every call to a throwing function needs try, and a function that lets an error propagate must itself be throws — so the failure path is documented all the way up the call stack, which is what a return code never manages. Swift errors are not exceptions in the C++ sense: there is no stack unwinding machinery and no cost when nothing throws, because throws compiles to an extra return register.

The value and the failure cannot both be present and neither can be absent, because they are two cases of one enum — so the C column’s last hazard, reading value after a failure, has no spelling. map and flatMap transform the success case and pass the failure through untouched, which is how a chain of fallible steps becomes one expression rather than a ladder of checks.

assert is removed in a release build, exactly like C’s; precondition survives it, which is what you want for anything validating input rather than checking your own reasoning; and fatalError is always present and has return type Never, so the compiler knows the code after it is unreachable and a guard ending in one satisfies the "must leave the scope" rule. The three cover what C leaves to assert plus a hand-written abort.

Exhaustiveness is the feature that pays off later: add a fourth case to the enum and every switch over it stops compiling, listing exactly the places that need updating. C offers -Wswitch, which catches the same thing for enums only, is a warning, and is off unless you asked. The keyword fallthrough exists for the rare case you genuinely want C’s behavior, and having to write it is the point.

A tuple is a value type laid out like a struct, so returning one costs nothing extra — and unlike the out-parameter form there is no half-initialized state to reach. What a tuple cannot do is carry methods, conform to a protocol, or be extended, which is the line to draw: when the pair starts being passed around and reasoned about, promote it to a struct.

Swift generics are specialized: the optimizer emits a separate copy for each concrete type it sees, so Stack<Int> stores raw Ints with no boxing and no indirection — the same layout you would have written by hand. That is the difference from Java’s erased generics, and it is why a generic container in Swift has no per-element cost.

The constraint is also what makes the body legal: without T: Comparable the compiler rejects left >= right, because it cannot know the type has it. That is the opposite of a C++ template, which type-checks only when instantiated — so a Swift generic either compiles for every conforming type or does not compile at all, and the error names the constraint rather than a line inside a library.

Every rule you know applies again inside this block: nothing is bounds-checked, the memory is not managed, and forgetting the deallocate is a genuine leak — which is why the defer is written on the line after the allocation. The extra step with no C counterpart is initialize/deinitialize: Swift distinguishes memory that has been allocated from memory that holds a valid value, and for a type with a reference count that distinction is what keeps the counting correct.

size is the bytes the value actually occupies — 5 here, four for the Int32 and one for the UInt8 — while stride is that rounded up to the alignment, 8, and is the number that matches C’s sizeof. Getting them mixed up when allocating is the classic mistake: capacity * size under-allocates for any type with tail padding, and stride is the one to multiply by. The layout of a plain Swift struct is not guaranteed to match a C struct unless you say @frozen or go through an imported C type, which the interop section covers.

The pointer is valid inside the closure and nowhere else — storing it and using it afterwards is undefined behavior, exactly as returning the address of a C local is. That is the whole design: Swift is willing to hand you the address, and insists on bounding the window in which it means anything. The same pattern appears as withUnsafeMutableBufferPointer for writing, and withUnsafeBytes for the untyped byte view.

No binding generator, no wrapper layer, no build step — the module is the C headers, imported. The reason it works is that Swift ships a Clang importer: it parses the real header, maps each declaration to a Swift one, and applies naming rules along the way. Notice what the conversion did quietly: a String literal became a NUL-terminated UTF-8 buffer for the call, and size_t came back as an Int you can print.

Three things arrive for free and are worth knowing about. The C struct becomes a Swift struct with the identical layout, so passing it to and from C copies nothing. A C enum becomes a real Swift enum, so a switch over it is exhaustive. And a function-like macro does not come across — only object-like ones that are simple constants — which is the one place the importer gives up and you write a small inline function in the header instead.

Both columns print the same sorted line, with the C library doing the sorting in each. @convention(c) is the annotation that makes the closure a genuine C function pointer, and it is why a capture is rejected at compile time rather than corrupting something later. MemoryLayout<Int32>.stride rather than .size is the right multiplier here for the reason two rows back — qsort wants the array stride.

The three offsets agree, and so does stride against C’s sizeof — both 12. What differs is size, which reports 10: Swift counts the bytes the value actually occupies and excludes the two bytes of tail padding that sizeof includes, which is why the Swift byte dump is two bytes shorter. Multiply by stride, never size, when allocating for a C API. And note that the agreement is observed rather than promised: Swift does not guarantee the layout of an ordinary struct, so when it must be right, declare it in a C header and import it. Both columns print the machine’s own byte order, so a wire format still needs explicit swapping.