ST-0027: Macro for getting the current source location

Hello Swift community,

The review of ST-0027 "Macro for getting the current source location" begins now and runs through August 13, 2026. The proposal is available here:

swift-evolution/proposals/testing/0027-sourcelocation-macro.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 main branch of swift-testing to your package:

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

Then, add a target dependency to your test target:

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

Finally, import Swift Testing using @_spi(Experimental) import Testing.

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

+1. This is a nice ergonomic improvement when writing wrappers which build more complex expectations on top of the Testing macros, and because it's restricted to the Testing library the past arguments against similar features around accidentally embedding file paths in production binaries don't really apply.

3 Likes

Perhaps this is too subjective of a comment, but it's rather unfortunate that usage has to be fully qualified (#Testing::sourceLocation) with foreign-feeling C++ style scope resolution. I wonder if this is because the name #sourceLocation reads very generally but - as the proposal mentions - the macro has requirements specific to testing. Could another name speak better to the macro's responsibility of marking out a test case location? e.g.: #testCaseLocation

2 Likes

I'm certainly open to other names, however the Testing:: requirement here is (as explained in the proposal) due to a compiler constraint that I hope we can resolve. If resolved, the constraint goes away.

The name #testCaseLocation specifically would be incorrect in the general case as the macro refers to the current source location (just as #fileID refers to the current file's ID, #line refers to the current line, etc.) not to the source location of the currently-running test case.

3 Likes

Overall, I am very sympathetic to solving this. I have felt the pain of declaring methods taking multiple of these parameters. I also acknowledge the minimum deployment constraints that Testing has to support running on older Apple OS versions.

Having said that I would love to see this solved in the standard library in addition to the Testing module as well. I could imagine a standard library macro and SourceLocation type to be more flexible around relative and absolute FilePaths to allow a single type and macro to cater to both audiences. So while I am +1 on this Testing proposal I would love to see a follow up proposal to the stdlib to solve this for everyone.

5 Likes