Swift Language Expert

Swift Language Expert

Non-obvious Swift language and standard-library techniques. This skill is about the language itself — not UI, not app architecture, not a test framework.

Agent Behavior Contract

When this skill is active, follow these rules strictly:

1. Language & stdlib only. SwiftUI → defer to swiftui-expert; app architecture / composition / where actor isolation goes in a layered app → ios-architecture-expert; test-framework syntax (@Test/#expect, XCTestCase), test doubles, async-test determinism → swift-testing-expert.
2. Prefer value types + copy-on-write for shared data; reach for a class only when you need identity, shared mutable state, or deinit/lifecycle.
3. Prefer opaque some over existential any when a function returns one concrete type; use any only for genuinely heterogeneous storage, and know it costs dynamic dispatch + boxing.
4. Use lazy for chained collection transforms over large sequences to avoid intermediate allocations; eager is fine for small or single-pass work.
5. Respect Unicode. Iterate Character (grapheme clusters) for user-perceived characters; never index a String by Int — use String.Index.
6. Prefer pattern matching (if/guard case, switch with tuples and where) over chained if let / boolean ladders.
7. Prefer structured concurrency (async let, withTaskGroup) over detached Task {} for child work. Where actor isolation belongs in an architecture is out of scope — defer to ios-architecture-expert.
8. Gate recent language features by Swift/toolchain version: ~Copyable/borrowing/consuming, typed throws, InlineArray, primary associated types, RangeSet.

Swift Technique Diagnostic Table

Guardrails

• Do not use a class where a struct (+ copy-on-write if needed) suffices — reach for reference types only for identity/shared-mutable-state/lifecycle
• Do not return any P when one concrete type is returned — use some P
• Do not index String by integer offsets — use String.Index; iterate Character for user-perceived characters
• Do not chain if let ladders where a guard case/switch reads clearer
• Do not spawn unstructured Task {} for child work that should be async let / a task group
• Do not solve SwiftUI, app architecture, or testing problems here — defer to the sibling skills
• Do not use bleeding-edge syntax without gating it by Swift/toolchain version

Reference Router

Open the smallest reference that matches the question:

• Control flow & functions
  • pattern-matching-and-control-flow.md — if/guard case, switch over tuples/ranges, optional patterns, labeled loops
  • functions-closures-keypaths.md — variadics, autoclosures, rethrows, overloading, key paths
• Types
  • custom-types.md — value semantics, copy-on-write, ~Copyable, callAsFunction, Comparable/literal conformances, recursive enums, property wrappers
  • protocols-and-generics.md — associated types, Self, some vs any, primary associated types, phantom types, constraints, hand-rolled type erasure
• Data
  • collections.md — lazy sequences, RangeSet/DiscontiguousSlice, ContiguousArray/InlineArray, sorting, mapValues
  • strings.md — String.Index, grapheme/Unicode handling, normalization, raw strings, custom interpolation
• Concurrency & errors
  • concurrency-and-errors.md — async/await, structured concurrency, AsyncSequence/AsyncStream, typed throws, global actors, Mutex, isolation escape hatches
• Tooling
  • debugging-and-organization.md — assertions, dump, CustomDebugStringConvertible, type subscripts, enum namespaces, compiler directives