ST-0023: Transferable Attachments

Evolution Proposal Reviews
1

Hello Swift community,

The review of ST-0023: Transferable Attachments begins now and runs through April 13, 2026. The proposal is available here:

swift-evolution/proposals/testing/0023-attachments-transferable.md at main · swiftlang/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review manager directly, please keep the proposal link at the top of the message.

Trying it out

To try this feature out, add a dependency to the jgrynspan/transferable-attachments branch of swift-testing to your package:

dependencies: [
  ...
  .package(url: "https://github.com/swiftlang/swift-testing.git", branch: "jgrynspan/transferable-attachments"),
]

Then, add a target dependency to your test target:

.testTarget(
  ...
  dependencies: [
    ...
    .product(name: "Testing", package: "swift-testing"),
    .product(name: "_Testing_CoreTransferable", package: "swift-testing"),
  ]

Finally, add the following imports to any source file that will attach a Transferrable value to a test:

import Testing
import CoreTransferable
@_spi(Experimental) import _Testing_CoreTransferable

Note: The extra product dependency and import _Testing_CoreTransferable statement are a side effect of how packages are built. They will not be required in the final implementation of this feature.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift Testing?
  • Does this proposal fit well with the feel and direction of Swift Testing?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

swift-evolution/process.md at main · swiftlang/swift-evolution · GitHub

Thank you,

Stuart Montgomery
Review Manager

5 Likes
[Pitch] Transferable Attachments
Testing Workgroup meeting April 20, 2026
[Accepted] ST-0023: Transferable Attachments
2

I'm curious why record() shouldn't be async and throwing. I think in nearly all cases, the Test itself is just going to be marked as async throws, so no special handling of the exception should be needed. In the proposal's current form, I would probably just use the feature as:

try await Attachment.record(.init(exporting: value))

I'm aware there is a precedent for this with Attachment.init(contentsOf url: URL), but I haven't seen a discussion on the omission of the record() overload in its review.

3

@grynspan might be better suited to answer this question, but let me share how I see it.

The decision to keep record() synchronous and non-throwing was intentional for two reasons.

One, developer experience: record() is conceptually a simple attachment operation, and introducing an async throws would break that expectation. I'd also note that a variant differing in both asyncness and throwability is arguably a different API rather than a true overload, which might add confusion at the call site.

Another, separation of concerns: any errors surfaced at the record() call site would originate from the underlying export operation, not from recording itself. We didn't want to conflate these two distinct responsibilities.

1 Like
4

Attachment.record(_:) is meant to be shorthand for "create an attachment and then record it". This shorthand may not be appropriate when the act of creating an attachment may have side effects.

(A weaker argument against it: the number of overloads required for Attachment.record(_:) grows combinatorically every time we need to consider an additional protocol constraint on the argument value, whereas we only need a single initializer on Attachment per protocol we care about.)

1 Like
5

ST-0023 has been accepted!