Swift 6.4 expands Embedded Swift with existential types, untyped throws, and metatypes

Embedded Swift is evolving to bridge the gap between full Swift and constrained environments like microcontrollers. The 6.4 release introduces support for existential types, untyped throws, and metatypes, which were previously restricted or unavailable. These changes make it easier to port existing Swift code to embedded targets, as the language subset now aligns more closely with full Swift. However, the added features come with trade-offs: dynamic language constructs can increase binary size and runtime overhead, particularly where heap allocations or indirect calls are involved.

The generalization of existential types in Embedded Swift is a significant step forward. Previously, only `AnyObject`-constrained existentials were supported, limiting their utility. Now, developers can use `any P` for any protocol `P`, including `Any` itself. This flexibility simplifies code sharing between embedded and non-embedded targets but introduces limitations. For example, generic functions cannot be called on existential types in Embedded Swift due to the compilation model, which requires all generics to be specialized. This constraint may require refactoring in some cases.

Untyped throws are another notable addition, enabling broader error handling patterns. Previously, Embedded Swift required explicit error types (e.g., `throws(ParsingError)`), which could complicate interoperability with full Swift code. Untyped throws align with full Swift’s behavior but may introduce heap allocations when throwing arbitrary `Error`-conforming values. For performance-critical code, typed throws remain the better choice to avoid runtime overhead.

Metatypes are now fully supported in Embedded Swift, including existential metatypes like `any (DefaultInitializable.Type)`. This change allows for more dynamic initialization patterns, such as factory methods, which were previously restricted. The addition of floating-point parsing and concurrency error handling further extends the standard library’s capabilities in embedded contexts. These improvements make Embedded Swift more practical for real-world applications but require developers to weigh the benefits against potential increases in code size and complexity.

The updates in Swift 6.4 reflect a deliberate balance between language expressiveness and the constraints of embedded systems. While the new features reduce friction for developers, they also introduce choices: teams must decide whether to adopt dynamic constructs or stick to more restrictive patterns to optimize for size and performance. The availability of these features in development snapshots allows for early testing, but production use will depend on hardware-specific validation and performance profiling.