---
title: "SE-0537: Section Placement Control for Functions"
framework: Swift Evolution Proposals
role: article
path: swift-evolution/0537-function-sections
---

# SE-0537: Section Placement Control for Functions

* Proposal: [SE-0537](0537-function-sections.md)
* Authors: [Doug Gregor](https://github.com/DougGregor)
* Review Manager: [Becca Royal-Gordon](https://github.com/beccadax)
* Status: **Active review (July 14...27, 2026)**
* Implementation: https://github.com/swiftlang/swift/pull/89740
* Review: ([pitch](https://forums.swift.org/t/pitch-extending-section-to-functions/87174)) ([review](https://forums.swift.org/t/se-0537-section-placement-control-for-functions/88298))

## Summary of changes

This proposal extends the `@section` attribute introduced in [SE-0492](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0492-section-control.md) to also allow functions to be annotated with `@section`. This can be useful in embedded systems where some code (for example the boot code for firmware) needs to be in a particular section in the binary.

## Motivation

The `@section` attribute specifies where a particular entity will be placed in an object file. Particularly in embedded environments, linkers and other tools expect certain kinds of symbols to be in specific sections. SE-0492 introduced support for `@section` for global and static variables, but left functions to a future direction. However, functions also require this support. A prominent use case is firmware entry points and booting schemes, which often require startup code to be in a predefined section:

```swift // code for the function is placed into the custom section @section("__TEXT,boot") func firmwareBootEntrypoint() { ... } ```

This motivation was also [outlined in the Future Directions of SE-0492](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0492-section-control.md#section-placement-for-functions).

## Proposed solution

Enable the `@section` attribute on all kinds of functions, including normal functions (`func`), initializers (`init`), deinitializers (`deinit`), closures, and accessors (`get`, `set`, etc.).

## Detailed design

The `@section` attribute can be applied to any kind of function. Some examples to show the syntax at various places:

```swift @section("__TEXT,boot") func firmwareBootEntrypoint() { ... }

struct MyBootConfig: ~Copyable {   @section("__TEXT,boot") init() {      registerCallback { @section("__TEXT,boot") in        ...     }   }

@section("__TEXT,boot") deinit { }

var bootPhase: Int {     @section("__TEXT,boot") get { ... }     @section("__TEXT,boot") set { ... }    } } ```

Unlike with `@section` on variables, there are no limitations on the use of `@section` for generic functions or functions within a generic context, because all functions go into a text section. This also means that `@section` can be applied to instance functions of types.

The `@section` attribute applies to the function and any related functions that the implementation produces for it. For example, when applied to an `async` function, each of the partial functions the implementation generates will respect the `@section` attribute. Similarly, when a `@section` attribute is applied to a generic function, it will also apply to any specialization of that generic function that is produced by the compiler, as well as the original generic definition. Finally, if the `main` function of a `@main` type has a `@section` attribute, the same section is used for the actual `main` entrypoints emitted by the compiler.

### Inferring `@section` on accessors, closures, and local functions

When `@section` isn't explicitly specified of an accessor or a closure, it can be inferred:

* For a closure or local function, `@section` will be inferred from its enclosing function (if there is one).   ```swift   @section("__TEXT,boot")   func firmwareBootEntrypoint() {     func helper() { // infers @section("__TEXT,boot")        }        registerCallback { // infers @section("__TEXT,boot")       ...     }   }   ```    * An accessor that provides read-only access (`get`, `borrow`, `yielding borrow`, etc.) that is synthesized by the implementation will infer `@section` from one of these accessors that was written explicitly.

* An accessor that provides read-write or write access (`set`, `mutate`, `yielding mutate`, `init`, `didSet`, `willSet`) that is synthesized by the implementation will infer `@section` from one of these accessors that was written explicitly. For example:   ```swift     var scratchSpace: MutableSpan<UInt> {       @section("__TEXT,boot") borrow { ... }       // synthesized "get" will infer @section("__TEXT,boot") from 'borrow'              @section("__TEXT,boot") mutate { ... }       // synthesized "set" will infer @section("__TEXT,boot") from 'mutate'      }   ```

Note that there is no inference of `@section` from a variable to its accessors, because code and data tend to be in different sections. Local types (and members thereof) also do not have sections inferred.

### Lifting restriction on didSet/willSet

SE-0492 placed this restriction on variables with `@section`:

* the variable must not have property observers (didSet, willSet)

This restriction is unnecessary, and is lifted by this proposal. The `didSet` or `willSet` can have a `@section` attribute on them, which will then be used for inference on the actual accessor (e.g., `set`) that the implementation synthesizes a symbol for.

## Source compatibility

This is a pure extension with no source compatibility impact.

## ABI compatibility

The `@section` attribute deliberately places an entity into a specific section.

## Implications on adoption

This feature can be freely adopted and un-adopted in source code with no deployment constraints and without affecting source compatibility. ABI is covered above.

## Future Directions

### Separate "data" and "function" section attributes

Some declarations in Swift involve emitting both data and function symbols. For example, when defining a type, there can be both a metadata symbol (data) and also a metadata accessor function (a function). Neither this proposal nor SE-0492 allows a `@section` attribute on a type definition, but if it did, we would need a way to express different sections for data vs. functions. For example, it could look like this:

```swift @section(data, "__DATA,mysection") @section(function, "__FUNCTION,mysection") public struct MyStruct { ... } ```

A `@section` that specifies neither `data` nor `function` would only apply in the places where the determination is unambiguous, as covered by this proposal and SE-0492. New places that emit both data and function symbols, such as type definitions, extensions, or protocol conformances, could then make use of this new syntax.