The Swift Evolution proposal SE-0486 focuses on improving the experience of enabling individual Swift features by providing an integrated mechanism for automatically producing source code modifications. The motivation behind this proposal is to help project maintainers preserve source and binary compatibility when enabling upcoming features, which can be challenging without tools to assist in detecting inadvertent changes or performing migration tasks. The proposed solution introduces the concept of a migration mode for experimental and upcoming features, allowing developers to declare their intent to migrate code in order to preserve compatibility once the feature is enabled. This migration mode will support upcoming features with mechanical migrations, providing compiler warnings with fix-its to ensure code behavior remains consistent under the feature.
The proposal introduces OutputSpan and OutputRawSpan types to allow for safer and more controlled initialization of memory in Swift. These types help address the drawbacks of using explicitly unsafe functions for memory initialization, making them more suitable for security-conscious environments. OutputSpan provides a way to delegate memory initialization by managing a range of contiguous memory with a mix of initialized and uninitialized elements. The proposal also includes extensions to standard library types like Array and String to take advantage of OutputSpan for delegated initialization. Additionally, the proposal introduces the @lifetime attribute to establish a lifetime relationship between non-escapable returned values and callee bindings.
The proposal aims to allow @dynamicMemberLookup subscripts to take additional arguments with default values, making it easier to provide more expressive and flexible APIs. Currently, subscripts eligible for dynamic member lookup can only take one argument labeled dynamicMember, but this proposal suggests relaxing that requirement. By allowing additional arguments with default values, developers can pass extra information to subscripts without affecting the call sites. This change would mainly impact types that opt into @dynamicMemberLookup and offer subscripts with additional arguments, making it easier to work with dynamic member lookup in Swift.
The proposal suggests introducing a more concise syntax for declaring inline arrays using type sugar. Currently, declaring the InlineArray type is more cumbersome compared to dynamically-sized arrays. The proposed solution introduces a new syntax using the x character to represent the size of the array, making declarations more succinct and readable. This new syntax does not impact existing code compatibility or the ABI, as it is resolved at compile time. Future directions may include introducing a value sugar equivalent and exploring flattened multi-dimensional arrays syntax. Alternative delimiters were considered, but x was chosen for its clarity and lack of ambiguity.
The proposal suggests extending Swift key paths to include references to method members like instance and type methods, as well as initializers. This would make the API more consistent by unifying instance and type member access. While not covering all method types yet, this change lays the foundation for more expressive and type-safe APIs. The proposed solution allows key paths to reference methods and initializers, enabling dynamic invocation and creating new instances based on those references. Overall, this feature enhances the flexibility and usability of Swift key paths, offering benefits like abstraction, reusability, and type safety.
The proposal aims to introduce a new typealias called DefaultIsolation that allows specifying default actor isolation in individual source files within a module. This provides flexibility in opting out of main actor isolation in specific files within a main-actor-by-default module or opting into main actor isolation in a nonisolated-by-default module. The proposed solution involves writing a private typealias named DefaultIsolation with an underlying type of MainActor for main actor isolation or nonisolated for nonisolated declarations in the file. This change is not expected to have significant source or ABI compatibility issues and aims to improve the approachability of data-race safety in concurrent code.
The proposal introduces a new way to observe changes in Swift models using an AsyncSequence, allowing for asynchronous sequences of values to be tracked. The motivation behind this proposal is to provide a safe and ergonomic solution for observing changes in non-SwiftUI systems, similar to the ease of use provided by SwiftUI. The proposed solution includes a new type called Observations, which emits new values when something within a closure changes, making it easy to write asynchronous sequences while ensuring safe concurrency access. The design focuses on handling tearing and sharing behaviors to ensure consistent and non-torn values are emitted during observations. This proposal aims to simplify tracking changes in models and provide a centralized mechanism for implementing asynchronous sequences in Swift.
The proposal suggests introducing new accessors, yielding mutate and yielding borrow, to allow for computed properties and subscripts to be implemented without requiring a copy. These new accessors use a coroutine that pauses and resumes execution using the yield keyword. This feature aims to improve performance, especially for noncopyable types, by avoiding unnecessary copying. It has been available experimentally in recent compiler builds and provides a more efficient way to work with values, reducing potential performance pitfalls and allowing for expressive APIs.
The Swift Package Manager currently supports linking against binary dependencies on Apple platforms only. This proposal, SE-0482, aims to enable providing static library dependencies with a C interface on non-Apple platforms that rely only on the standard C library. The motivation behind this proposal is to allow packages to vend libraries that cannot be built in Swift Package Manager for technical or legal reasons. The proposed solution extends artifact bundles to include a new artifact type called staticLibrary, which includes information such as the library file, headers, and module maps. Additionally, an auditing tool is suggested to ensure safe usage of library artifacts across supported platforms. This proposal focuses on C libraries only, and future support for distributing Swift libraries is considered a separate challenge.
This proposal introduces the ability to use weak with let in Swift, allowing weak references to be declared as constants rather than requiring them to be mutable. This change is motivated by the need to make classes and closures with weak references compatible with Sendable requirements for concurrency. Currently, weak properties must be mutable, preventing classes with weak properties from being Sendable. The proposal addresses this limitation by allowing weak let declarations, which ensures that weak references can be used safely in concurrent contexts without the need for workarounds. The proposal maintains existing behavior for weak on function arguments and computed properties, and ensures that explicit weak captures are immutable like other explicit captures.
The proposal suggests adding a new string interpolation syntax to provide a default string when interpolating an optional value. The motivation behind this is to simplify the process of handling optional values within string interpolations, as the current methods can lead to verbose or error-prone code. The proposed solution introduces a new interpolation overload that allows developers to specify a default string regardless of the type of the optional value. This addition aims to improve code clarity and encourage the use of sensible defaults. The impact of this change is expected to enhance the readability and maintainability of code that utilizes string interpolations, especially when dealing with optional values.
This proposal suggests adding a new @abi attribute in Swift, allowing developers of ABI-stable libraries to make minor changes to declarations without breaking compatibility. The motivation behind this proposal is to enable library maintainers to update or correct existing declarations for various reasons, such as adopting new language features, correcting mistakes, or renaming confusing APIs. By using the @abi attribute, developers can make changes like adjusting parameter sendability or renaming declarations while preserving backward compatibility. This feature aims to provide more flexibility and control over the ABI of functions, initializers, properties, or subscripts without requiring deep knowledge of compiler internals.
The proposal introduces the concept of "system epochs" to Swift's SuspendingClock and ContinuousClock types, which represent the reference instant or "zero" point for these clocks. This is useful for comparing durations within a system, even across different processes or languages that use the same system facilities. Two new properties, systemEpoch, will be added to these clock types to access the system epoch. This change is purely additive and does not impact existing ABI compatibility. The proposal considered alternative approaches but decided to add the properties directly to the clocks for better discoverability and usability.
The proposal introduces a new feature called "immediate tasks" in Swift Concurrency to allow tasks to start running synchronously from the caller's context before yielding control back upon encountering a suspension point. Currently, entering an asynchronous context in Swift incurs creating and scheduling a task for later execution, which can be wasteful for tasks that perform minimal work. The proposed solution aims to address situations where tight control over execution is required, especially for tasks that run quickly without suspending. This new behavior can be beneficial for scenarios like UI or performance-sensitive use cases, where tasks need to start immediately on the calling context.
This proposal aims to enhance the custom isolation checking capabilities for SerialExecutor in Swift concurrency. Previously, the APIs followed a "pass or crash" pattern, where a crash occurred if an incorrect assumption about isolation was made. The motivation behind this enhancement is to provide a way for libraries to issue warnings instead of crashing when incorrect assumptions are made, allowing for more careful adoption of strict concurrency checks.
The proposed solution introduces a new protocol requirement isIsolatingCurrentContext() to the SerialExecutor protocol. This function can be called by the Swift runtime to check for isolation violations at runtime and potentially issue warnings instead of crashing. By implementing this new API, developers can receive more informative error messages when isolation failures are detected, improving the debugging experience and allowing for a smoother transition to stricter concurrency checks.
Overall, this enhancement offers a more flexible approach to handling isolation violations, providing developers with the option to issue warnings instead of crashing, and enabling the Swift runtime to offer detailed error messages for better debugging.
This proposal adds a Hashable conformance to Async(Throwing)Stream.Continuation to simplify working with multiple streams. The motivation behind this is to make it easier for client code to identify and compare continuations when handling multiple AsyncStreams. Currently, without Hashable conformance, an artificial identifier needs to be associated with each continuation, leading to inefficiencies. The proposed solution is to add Hashable conformance to Async(Throwing)Stream.Continuation, ensuring that all copies of the same continuation compare as equal. This change is additive and should not impact source or ABI compatibility, but adopters will need the new version of the standard library for this feature.
The proposal introduces MutableSpan and MutableRawSpan types to delegate mutations of exclusively-borrowed memory in Swift. The motivation behind this proposal is to provide a safe and non-unsafe way to allow direct access for modifying internal representations of standard library container types. The proposed solution involves introducing these new types that manage mutations of typed and untyped memory, respectively, while ensuring memory safety, lifetime safety, and bounds safety.
MutableSpan allows mutating a type's contiguous internal representation, while MutableRawSpan allows mutations in memory representing heterogeneously-typed values. The standard library will provide mutableSpan computed properties to facilitate safe and composable mutation access, replacing existing closure-taking functions like withUnsafeMutableBufferPointer. These computed properties establish a new lifetime relationship between the returned MutableSpan instance and the instance that provided it, enabling safer mutation handling in Swift code.
The proposal aims to enhance Swift's Standard Library by allowing Optional and Result to hold instances of nonescapable types. This builds upon previous work on noncopyable types and nonescapable types in the Standard Library. The motivation is to support nonescapable types in Swift, enabling developers to use them in API surfaces without disruption. By extending constructs like MemoryLayout, Optional, and Result to support nonescapable types, the proposal aims to provide a smoother experience for developers working with these types. The goal is to implement these enhancements with minimal disruption to existing code that assumes copyability and escapability.
The proposal introduces UTF8Span as a way to efficiently and safely process Unicode data over contiguous memory storage. It aims to provide a non-escaping type similar to Span for working with UTF-8 bytes without the need to create a new String instance, which can be memory-intensive and inefficient. By exposing the UTF-8 buffer and its methods publicly, developers can access advanced functionality for processing Unicode data more effectively. The proposal also addresses the importance of UTF-8 validity for security and efficiency, proposing new APIs to identify encoding errors in UTF-8 content. Overall, UTF8Span offers a more optimized and secure approach to handling UTF-8 data in Swift.
The proposal introduces a new attribute called @specialized in Swift to allow authors of generic functions to create pre-specialized versions of those functions for specific types. This attribute helps optimize performance by generating custom implementations of the function for specific types, improving speed significantly compared to unspecialized versions. The motivation behind this proposal is to address scenarios where the compiler lacks information about concrete types at the call site, leading to slower execution of unspecialized code. By using @specialized, authors can ensure that optimized versions of their functions are generated for specific types, even when the compiler cannot infer the types at the call site. This enhancement is particularly useful for improving performance in scenarios involving type erasure or when authors want to hide implementation details in ABI-stable binary frameworks.
This proposal aimed to address the lack of Collection conformance for the sequence returned by the enumerated() method in Swift. By adding these conformances, the EnumeratedSequence type can now be used in contexts that require a Collection, enabling benefits like improved performance and compatibility with SwiftUI views like List and ForEach.
The proposed solution involved conditionally conforming EnumeratedSequence to Collection, BidirectionalCollection, and RandomAccessCollection based on the conformance of its underlying base collection. This change is additive to the ABI but may impact runtime casting mechanisms and APIs like underestimatedCount.
The proposal considered alternatives like adding LazyCollectionProtocol conformance for EnumeratedSequence or providing an enumerated() overload for Collection, but opted for a small, focused change to avoid potential source compatibility issues and complexities.
The proposal aims to add properties to standard library types that provide access to their internal representation in a safe manner. Currently, direct access to internal data is possible but only through unsafe methods, which are not ideal for security-conscious environments. By introducing computed properties that return non-escaping and copyable values like Span, developers can access internal data without compromising safety. This change simplifies code that relies on unsafe methods like withUnsafeBufferPointer() and enables better composability. The proposal enhances safety by preventing overlapping accesses and allows for more flexible code evolution.
The Swift Package Manager currently enforces @testable import for all targets in a package, even if not all targets need it. This proposal suggests adding a new setting to specify whether testing should be enabled for a specific target, allowing developers to disable @testable import when not needed. This can be helpful for reducing exported symbols in shared libraries on Windows and improving debug build performance. The impact on existing packages is minimal as the default behavior will remain the same, but developers will have more control over enabling or disabling @testable import as needed. No alternatives were considered for this proposal.
The proposal suggests adopting the mimalloc memory allocator for the Swift toolchain on Windows to improve compiler performance. By using a more efficient allocator, compile times can be reduced, enhancing developer productivity. Testing showed a 4% decrease in build time when using mimalloc, making it a beneficial choice for the toolchain. This change will require additional files to be built and shipped with the toolchain, but the impact on overall build time is minimal. The adoption of mimalloc does not affect source compatibility or the ABI of the code, focusing solely on improving toolchain performance.
The proposal suggests adding support for lookbehind assertions in Swift's regular expression engine. Lookbehind assertions are a feature commonly found in modern regex engines that allow matching patterns based on what precedes the current position in the input string.
The proposed solution involves implementing arbitrary-length lookbehind regexes by performing matching in reverse, from right to left. This feature is similar to lookahead assertions but allows matching patterns based on what comes before the current position.
The impact of this proposal is that it enhances the expressivity of Swift's regex capabilities, bringing it more in line with other programming languages like Python, Java, and JavaScript. The proposal is source-compatible and ABI-compatible with existing code, and it may require a new version of the standard library and runtime for adoption. Additionally, future directions include supporting PCRE's \K feature and exploring a reverse matching API.
The proposal aims to enhance Swift Package Manager (SwiftPM) by introducing new settings to control how the Swift, C, and C++ compilers handle warnings during the build process. Currently, SwiftPM lacks a unified way to manage warnings across different languages, leading developers to resort to using unsafeFlags or sticking with default warning settings. The proposed solution includes adding new methods to SwiftPM's build settings API, enabling developers to finely tune warning controls for Swift, C, and C++ code. By allowing developers to specify the severity and treatment of warnings, this enhancement will provide more flexibility and control over the build process, ensuring that warnings are managed consistently across different languages.
The proposal introduces the concept of isolated conformances in Swift to address the issue where types isolated to a global actor, like @MainActor, cannot conform to protocols due to isolation mismatches. Currently, workarounds involving marking functions as nonisolated or using MainActor.assumeIsolated are needed, which can be error-prone and result in boilerplate code. The proposed solution of isolated conformances allows types to provide conformances that are restricted to a specific global actor, ensuring data race safety statically without the need for boilerplate. This change improves the approachability of data-race safety and enables types isolated to a global actor to integrate more seamlessly with Swift code using generics and libraries.
This Swift Evolution proposal, SE-0469, introduces new APIs that allow developers to name their Swift Tasks for better identification in debugging and profiling tools. The motivation behind this proposal is to provide developers with the ability to label tasks, similar to previous concurrency technologies like Pthread or Grand Central Dispatch. By allowing developers to name tasks, they can easily identify which task is running or causing issues in their code. The proposed solution adds optional name parameters to Task creation APIs, enabling developers to provide names for their tasks during creation. Additionally, APIs for naming tasks in task groups are also introduced, enhancing the debugging and profiling experience for Swift concurrency code. The proposal has been implemented in Swift 6.2, providing developers with a more user-friendly way to manage and identify tasks in their asynchronous workloads.
This proposal aims to improve data-race safety by introducing a new compiler setting to infer @MainActor isolation by default within a module. This helps reduce false-positive data-race safety errors in sequential code that doesn't use concurrency. By opting in to default single-threaded behavior on a module-by-module basis, developers can avoid unnecessary diagnostics and make their code more approachable, especially for those new to Swift. The proposal introduces a -default-isolation compiler flag to specify the default isolation within a module as either MainActor or nonisolated. This change allows unannotated code in the module to be implicitly isolated to @MainActor, making it easier to work with single-threaded programs.
The SE-0463 proposal aims to improve data-race safety in Swift by automatically importing completion handler parameters from Objective-C methods as @Sendable functions. This change helps prevent data races and potential runtime crashes for code calling APIs from actor isolated contexts. By defaulting completion handlers to @Sendable, Swift ensures safer concurrency handling. Additionally, the proposal includes a mechanism to opt-out of @Sendable for completion handlers that do not cross isolation boundaries. This change has no impact on source or ABI compatibility and enhances the approachability of concurrency in Swift.
The Task Priority Escalation APIs proposal aims to introduce user-facing APIs that allow developers to participate in task priority escalation within Swift Concurrency. Task priority escalation is crucial for avoiding priority inversion issues and for improving the performance of certain operations.
The motivation behind this proposal is to provide a way for developers to manually handle task priority escalation in scenarios where automatic escalation may not be sufficient or possible. For example, when working with unstructured tasks or when needing to propagate priority changes across process boundaries.
The proposed solution includes adding APIs that enable developers to react to priority escalation events within a block of code and to trigger priority escalation explicitly without relying on workarounds like creating new tasks solely for escalation purposes. These APIs will offer more control and flexibility for handling task priorities in complex concurrency scenarios.
Overall, this proposal aims to enhance the Swift Concurrency model by empowering developers to manage task priorities effectively in diverse use cases, ensuring better performance and correctness in concurrent programming.
This Swift Evolution proposal, SE-0461, aims to improve the usability and safety of async functions in Swift. The current behavior of nonisolated async functions can lead to confusion and potential data race issues. To address this, the proposal suggests changing the default behavior of nonisolated async functions to run on the caller's actor. This means that async functions will no longer automatically switch off the caller's actor, reducing the risk of data races. The proposal also introduces new syntax to explicitly specify when an async function should switch off an actor. Overall, this change simplifies the behavior of async functions and promotes better concurrency practices in Swift code.
The Opt-in Strict Memory Safety Checking proposal aims to provide a stricter level of memory safety in Swift for projects that require it. Memory safety is crucial for preventing runtime errors that can lead to crashes, data corruption, and security vulnerabilities. While Swift already offers memory safety features, some projects may want stronger guarantees. This proposal introduces opt-in strict memory safety checking to identify and discourage the use of unsafe constructs in Swift code. It focuses on five dimensions of memory safety: lifetime safety, bounds safety, type safety, initialization safety, and thread safety. By opting into this feature, developers can ensure their code meets higher memory safety standards without compromising interoperability with existing Swift code.
The proposal aims to enhance the Duration type in Swift by introducing direct support for attoseconds using the Int128 type. Currently, working with attoseconds in Duration involves cumbersome and potentially inefficient code. By adding a new property attoseconds and an initializer init(attoseconds: Int128), developers can now easily access and create Duration values directly from attoseconds, simplifying code and improving performance for high-precision time calculations. This change is additive and does not impact existing code compatibility, providing a more efficient and seamless way to handle attoseconds within Duration.
This proposal introduces a new type called InlineArray to the Swift standard library. The motivation behind this addition is to provide a fixed-size array that is stack-allocated, avoiding the overhead of heap allocation present in regular Array types. InlineArray allows for a known quantity of elements to be stored on the stack, providing benefits in terms of performance and memory usage, especially in scenarios where heap allocations are not ideal. The proposed solution involves defining InlineArray as a noncopyable struct that can store potentially noncopyable elements, with the memory layout determined by the size and alignment of its elements. This addition aims to offer a safer and more efficient alternative to using tuples or unsafe buffer pointers for fixed-size arrays in Swift.
This proposal introduces the ability to parameterize generic types with literal integer parameters in Swift. The motivation behind this change is to enable the creation of fixed-size or fixed-capacity collections with inline storage more easily. By allowing generic types to be parameterized by integer parameters, developers can reuse library implementations for various sizes and capacities, leading to more efficient and flexible code. The proposed solution includes syntax for declaring and using integer generic parameters, which can be instantiated with literal integer arguments or from the surrounding generic environment. This enhancement also allows for stronger static guarantees in APIs by carrying integer information in type information.
Motivation: In Swift, identifiers are limited to specific characters defined by the language's grammar. While this limitation is generally reasonable, there are cases where more flexibility in naming would be beneficial. For example, in test naming and when dealing with externally-defined entities with names that don't fit Swift's rules for identifiers.
Proposed Solution: This proposal introduces raw identifiers to the Swift grammar. These are backtick-delimited identifiers that can contain characters beyond the current set of allowed identifier characters. This allows developers to use more natural and descriptive names for certain entities, such as tests or externally-defined objects.
Impact: The addition of raw identifiers simplifies naming in situations where the current naming restrictions are too limiting. For example, in testing scenarios, developers can now provide more descriptive test names without redundancy. Additionally, when working with entities that have non-alphabetic or numeric names, developers can now use more natural naming conventions without resorting to workarounds like adding underscores. Overall, this change enhances the expressiveness and readability of Swift code.
The "Package traits" proposal addresses the need for package authors to provide configurable compilation and optional dependencies in Swift packages. This is important as the Swift package ecosystem has grown, and packages are used in various environments like embedded systems or Wasm. The proposal introduces a new feature called "package traits," which allows authors to define traits in their Package.swift file to express conditional compilation and optional dependencies. Package users can customize enabled traits when declaring dependencies, enabling flexibility in package usage. This feature helps in scenarios like pluggable dependencies, configurable behavior for different ecosystems, replacing environment variables in package manifests, and introducing experimental APIs. The proposal has been implemented in Swift 6.1.
The proposal aims to introduce a new keyword, nonisolated, that can be applied to type and protocol declarations to prevent global actor inference in Swift. This is useful when a programmer wants to explicitly opt out of global actor inference on a type or protocol. The proposal also extends the usage of nonisolated to improve usability, such as allowing it on stored properties for better control over actor isolation. By allowing nonisolated on declarations, programmers can easily prevent global actor inference without resorting to complex workarounds. This change simplifies code and makes it clearer where global actor isolation is being inferred from.
The proposal introduces Span<T>, which allows safe access to contiguous memory in Swift without compromising memory safety. It aims to enhance the performance of Swift code while maintaining properties like temporal safety, spatial safety, definite initialization, and type safety. Span provides a borrowed view of contiguous memory without copying the data, ensuring that the original container cannot be modified or destroyed while the Span is in use.
By using Span, developers can efficiently process values in contiguous memory without resorting to unsafe practices like UnsafeBufferPointer. This new type helps prevent unsafe pointer usage, bounds-checks every access for spatial safety, and ensures that memory is always initialized. Span is designed to replace APIs that currently use Array, UnsafeBufferPointer, Foundation.Data, etc., when the owning container does not need to be escaped.
Overall, Span is a valuable addition to Swift for local memory processing, providing a safer and more performant alternative to existing memory access methods.
This proposal introduces a new type constraint called ~Escapable in Swift, which allows developers to mark types that can be locally copied but cannot be assigned or transferred outside of the immediate context. This helps improve performance and safety in highly constrained environments by enforcing compile-time lifetime controls. By marking types as nonescapable, developers can opt into specific usage limitations that the compiler can verify automatically, leading to more efficient management of values that do not escape. This proposal complements the existing ~Copyable types and sets the stage for future enhancements like lifetime-dependency constraints for safe pointer usage.
The proposal aimed to improve the printed descriptions of String.Index in Swift by conforming it to CustomDebugStringConvertible. Previously, printing string indices resulted in unclear and unhelpful output, making it challenging to work with strings in Swift. The proposed solution added the CustomDebugStringConvertible conformance to String.Index, allowing for more informative and useful output when printing string indices for debugging purposes. This change provides developers with essential information such as storage offset, encoding type, and transcoded offset value, making it easier to understand and work with string indices. The implementation of this proposal has been completed and is available in Swift 6.1, enhancing the debugging experience for developers working with strings in Swift.
The Swift Evolution proposal SE-0444, which has been implemented in Swift 6.1, addresses the inconsistency in the visibility rules for member declarations compared to top-level declarations when importing modules. Previously, member declarations were visible even if the module introducing them was only transitively imported, leading to unexpected behavior and potentially ambiguous calls. The proposed solution unifies the behavior by ensuring both member and top-level declarations are resolved from the same set of visible modules in a source file. This change aims to improve consistency, reduce ambiguity, and enhance developer understanding of import visibility rules in Swift.
This proposal aims to provide more precise control over how the Swift compiler emits warnings by introducing new options. The current options are limited, leading to difficulties for users who want to upgrade warnings to errors selectively. The proposed solution suggests adding flags like -Werror and -Wwarning that allow users to control warnings based on their diagnostic group. The proposal introduces the concept of diagnostic groups, which are stable identifiers for errors or warnings. Users can specify these new flags along with existing ones, with the "last one wins" rule determining the behavior. Additionally, a new flag, -print-diagnostic-groups, is introduced to display diagnostic group names along with warnings for better understanding and organization.
The proposal, SE-0442, focuses on simplifying the use of TaskGroup and ThrowingTaskGroup by allowing the compiler to infer the generic type ChildTaskResult in most cases. Currently, users must specify this type explicitly when creating a task group, which can be confusing for new users. The proposed solution adds a default argument for ChildTaskResult.self in the withTaskGroup function, enabling the compiler to infer the type in many scenarios. This change simplifies the API design, making it easier for users to work with task groups, especially when dealing with types like Void. The implementation of this proposal has been accepted and will be available in Swift 6.1.
The proposal aims to clarify the terminology surrounding Swift language versions by introducing the term "language mode" to differentiate it from the toolchain version. This change is intended to reduce confusion in the Swift community. The proposal suggests using the term "language mode" in Swift compiler options and Swift Package Manager APIs, deprecating the use of "Swift version" in this context. The impact of this proposal is mainly on tooling and API naming conventions, making it easier for developers to understand and work with different language modes in Swift development.
The proposal introduces a new debugging macro called @DebugDescription in Swift's standard library. This macro allows data types to specify a custom summary for the debugger, improving the debugging experience and simplifying the maintenance of debugger type summaries. It can be used instead of or in addition to CustomDebugStringConvertible conformance for custom use cases. By sharing a debugDescription definition between Swift and the debugger, developers can benefit from a more seamless debugging process, and the debugger can provide more accurate and useful information about data types. This change aims to enhance the debugging workflow and make it easier to customize how data is displayed during debugging sessions.
This proposal, now implemented in Swift 6.1, allows the use of trailing commas in symmetrically delimited comma-separated lists. The motivation behind this change is to improve development quality of life by making it easier to append, remove, reorder, or comment out elements in lists. The proposal adds support for trailing commas in various contexts like tuples, parameter lists, subscripts, closure capture lists, generic parameters, and string interpolation. However, trailing commas will not be supported in certain cases like if, guard, and while condition lists, enum case label lists, switch case labels, inheritance clauses, and generic where clauses. Overall, this change aims to enhance code flexibility and readability in Swift.
The proposal introduces metatype keypaths, which allow key path expressions to reference static properties of a type. This feature addresses challenges like database lookups and verbose workarounds for accessing static properties. The proposed solution involves allowing keypath expressions to define a reference to static properties using a .Type syntax. This change enhances language semantics and provides a more straightforward way to access static properties. While this feature breaks source compatibility for key path expressions that reference static properties after subscript overloads, it does not impact ABI compatibility. Developers need to rebuild modules to enable this feature when forming key paths to static properties of types from older modules. This enhancement opens the door for potential future directions like key paths to enum cases.
The motivation behind SE-0437 was to adapt the Standard Library to support noncopyable types, which were introduced in a previous proposal (SE-0427). This change aimed to eliminate the assumption that everything is copyable in Swift, allowing for more flexibility in handling ownership of entities passed between functions. The proposal focused on making core changes to the Standard Library to enable building generic abstractions using noncopyable types. While these changes only affected a small subset of the API surface, they were crucial for paving the way for future enhancements in this area. The implementation of this proposal marks the first step in a series of planned improvements to support noncopyable types in Swift.