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 by email. When emailing the review manager directly, please include "SE-0537" in the subject line.
Trying it out
If you'd like to try this proposal out, you can install a toolchain supporting it using swiftly install main-snapshot or by other means documented on swift.org. Any development snapshot from the main branch dated June 12, 2026 or later should do.
Note that the current implementation doesn't include some of the contextual inference rules specified in the proposal.
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?
Does this proposal fit well with the feel and direction of Swift?
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
Shouldn't @section on a function place a function pointer in that section instead of the whole function code ? At least in a data section, that's what would be expected since it's not executable.
I tried to do that while ago with the existing "data" implementation but ran into issues (see here and here). The use case would be to reproduce something similar to __attribute__((constructor)) or Objective-C +load methods.
So maybe if this use case is ever supported, the syntax should anticipate both needs ? With the current proposal there would be no way to differentiate what outcome is wanted.
For accessors, we're inferring the section on accessors that the implementation synthesizes from the accessors that the user writes. I think that's easily defensible.
My thinking is that closures and local functions are generally considered to be part of the enclosing function, so I'd expect them to be colocated. You can opt out by spelling out the normal section (@section("__TEXT,__text") or whatever) on local functions/closures you don't want to propagate to, or just move them out. I could imagine introducing syntax to make that easier---@section(default) or something---but your question is making me reconsider the inference rule. This is very much a low-level, power-user feature, and perhaps it's best to just be explicit on local functions and closures.
If you want a function pointer, create a variable of function type and use @section to put the pointer into a specific data segment. This proposal's use of @section is about the executable code of functions.
Those seem like bugs, independent of this proposal.
No, but you only need to specify it if you’re using @section for something else, and that @section attribute is already platform-specific. Whether @section should be designed to reduce or accommodate the platform-specific meaning of section names was discussed during the review for @section on variables.
I think this is the correct answer, but I'll note that the correct type is the little-documented @convention(thin), which might deserve some love if this is the way to go.
I agree it feels brittle. IIRC, it's @section(".text") for ELF and PE-COFF.
Right.
I'm leaning toward requiring this to be explicit, effectively removing the "inference" section entirely. The inference for accessors is more like an implementation detail, since you can't write multiple kinds of overlapping access (e.g., set and mutate) anyway.