Skip to content

[ST-NNNN] Macro for getting the current source location#3312

Draft
grynspan wants to merge 3 commits into
mainfrom
jgrynspan/sourcelocation-macro
Draft

[ST-NNNN] Macro for getting the current source location#3312
grynspan wants to merge 3 commits into
mainfrom
jgrynspan/sourcelocation-macro

Conversation

@grynspan

@grynspan grynspan commented May 29, 2026

Copy link
Copy Markdown
Contributor

See here.

@grynspan grynspan self-assigned this May 29, 2026
@grynspan grynspan added workgroup: needs pitch This proposal needs to spend more time in pitch before it can be reviewed TWG Contains topics under the domain of the Testing Workgroup labels May 29, 2026
@grynspan grynspan force-pushed the jgrynspan/sourcelocation-macro branch from 29ab3c8 to 1d59663 Compare May 29, 2026 17:46
Comment on lines +162 to +164
- **Naming the macro something different.** We considered alternatives such as
`#here` and `#currentSourceLocation`, but `#sourceLocation` seems the most
appropriate name for it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this alternative, I'd find it helpful to reference back to the earlier section of the proposal where you mentioned the need to fully-qualify the macro with a module selector, and say that is the primary reason why an alternate name might be desirable. Just to clarify that this is more than run-of-the-mill bike shedding, there's a usability consideration. (Not that I think we should use a different name, I just think the bullet could provide more context.)

This macro, being underscored, is not formally supported, nor does it appear in
Swift Testing's documentation. It is also not sufficient to use something like
[`SourceLocation.init()`](https://developer.apple.com/documentation/testing/sourcelocation/init(fileid:filepath:line:column:))
as it will capture the _wrong_ source location. Thus, test authors have no

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could mention SE-0422 here as the underlying reason why a macro makes this possible

the module name when using this macro to avoid conflicting with the [`#sourceLocation(file:line:)`](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/statements/#Line-Control-Statement)
statement built into the Swift language.

The existing `#_sourceLocation` macro will be marked deprecated and renamed, but

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

…will be marked deprecated and renamed, …

The existing one will be renamed? (To what?)

@stmontgomery stmontgomery Jun 1, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, renamed: "Testing::sourceLocation" in @available. That's fair, but I found the phrasing a bit confusing since it sounded like you planned to rename the old macro. Maybe avoid that by just saying it will be deprecated?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will rephrase.


This macro, being underscored, is not formally supported, nor does it appear in
Swift Testing's documentation. It is also not sufficient to use something like
[`SourceLocation.init()`](https://developer.apple.com/documentation/testing/sourcelocation/init(fileid:filepath:line:column:))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not obvious to me why this init would have the wrong source location. It seems like it would be incumbent on the caller to pass in the correct arguments (as mentioned below) as the initialiser doesn't have any default values right?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See here for the proposal which explains it. And I agree it's non-obvious to readers who aren't aware of this macro nuance. I'd suggest mentioning that proposal

Comment thread proposals/testing/NNNN-sourcelocation-macro.md
/// // ...
/// }
/// ```
+@available(swift, deprecated: 100000.0, renamed: "Testing::sourceLocation")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we ought to deprecate it "for real" and not just use the 10000.0 "to-be-deprecated" marker. (That's what this is, right? Hope I didn't get that wrong.)

Do you think there's a compelling reason to not do that?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We generally don't do formal deprecation in the same release where we introduce a new replacement API as it causes undue noise/churn for developers. Which is why we have API_TO_BE_DEPRECATED in the first place.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Users wanting to maintain support for building using an older toolchain is a reasonable justification, thanks.

How about we clarify in the proposal that it will be deprecated using the special "to-be-deprecated" marker initially, but that later (after some settling period TBD), the intention is to lower the deprecated-in version down to a specific Swift version retroactively. That way, the proposal states the intent which is to deprecate it fully—it's just that we won't do so in the immediate term.

Comment thread proposals/testing/NNNN-sourcelocation-macro.md
@grynspan grynspan added workgroup: ready This proposal seems to be ready for evolution review and removed workgroup: needs pitch This proposal needs to spend more time in pitch before it can be reviewed labels Jun 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

TWG Contains topics under the domain of the Testing Workgroup workgroup: ready This proposal seems to be ready for evolution review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants