# SE-0550: \`@noSanitize\` attribute for functions

**URL:** <https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593>\
**Category:** Proposal Reviews\
**Created:** [September 16, 2026, 12:45pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593 "2026-09-16T12:45:24Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [September 16, 2026, 12:45pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/1 "2026-09-16T12:45:24Z")

</div>

Hello, Swift community!

The review of [SE-0550: `@noSanitize` attribute for functions](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0550-nosanitize-attribute.md) begins now and runs through **September 30th, 2026.**

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 me as the review manager by [DM](https://forums.swift.org/u/allevato/summary). When contacting the review manager directly, please put "SE-0550" in the subject line.

### 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 in the [Swift evolution repository](https://github.com/swiftlang/swift-evolution/blob/main/process.md).

With thanks in advance for your consideration,

Tony Allevato  
Review Manager

---

<div class="post-metadata">

**Author:** ![j-f1](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/j-f1/32/12287_2.png) [@j-f1](https://forums.swift.org/u/j-f1)\
**Post date:** [September 16, 2026, 2:28pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/2 "2026-09-16T14:28:26Z")

</div>

`noSanitize` doesn’t quite feel like the right grammatical placement for How about one of these alternatives? They feel a little more inline with how other attributes like `@specialized` and `@inlinable` sound to me.

```swift
@disableSanitizers(address, thread)

@sanitizer(thread, disabled)
@sanitizer(address, disabled)

@sanitization(disabled, for: thread, address)

```

Separately, I’m not quite sure of the abbreviation `memtag`. Have you considered expanding that?

---

<div class="post-metadata">

**Author:** ![ndrewh](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ndrewh/32/46240_2.png) [@ndrewh](https://forums.swift.org/u/ndrewh)\
**Post date:** [September 23, 2026, 5:55pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/3 "2026-09-23T17:55:15Z")

</div>

> [@j-f1](#):
>
> `@disableSanitizers(address, thread)`

Of the suggested options, I like this one. My preference is for `@noSanitize`, however, since it is shorter and closest to the `no_sanitize` spelling used by Clang and Rust.

> [@j-f1](#):
>
> Separately, I’m not quite sure of the abbreviation `memtag`. Have you considered expanding that?

Hmm. In clang, there are three different `memtag-*` [options](https://github.com/llvm/llvm-project/blob/dcd8f3442430915048c57164c193513d257e8ace/clang/include/clang/Basic/Sanitizers.def#L59-L62), and then `memtag` itself implies all three. Swift only supports one of the three, `memtag-stack`. There is only one LLVM-IR [attribute](https://github.com/llvm/llvm-project/blob/b313739c953857e0a686cc3b1b1d1b208897bfa9/llvm/include/llvm/IR/Attributes.td#L355), however, which is called `SanitizeMemtag` -- which is added to functions when `memtag-stack` is passed to the driver.

Because the name of the Swift driver option is memtag-stack, I think we should probably use `@noSanitize(memtagStack)` . This would also allow us to maintain exactly one `@noSanitize` kind per `-sanitize` driver option, which seems like it could be desirable.

---

<div class="post-metadata">

**Author:** ![James\_Dempsey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/james_dempsey/32/14336_2.png) [@James\_Dempsey](https://forums.swift.org/u/James_Dempsey)\
**Post date:** [September 23, 2026, 8:45pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/4 "2026-09-23T20:45:22Z")

</div>

I agree with @j-f1 that the proposed `@noSanitize` name does not fit well with the naming of other Swift attributes.

I realize that the naming directly mirrors the attribute name in LLVM. I do not know if there is a general rule of thumb that LLVM names should be treated as a term of art and used as-is.

Of the suggested naming, I would prefer a singular spelling of `@disableSanitizer(address, thread)`.

Since very often evolution proposals are used after the fact as documentation/reference, it would probably be useful to include a code example of using this attribute in one of its main use cases, showing conditionally adding the attribute for Embedded Swift.

I also think adding that bit of example code to the proposal helps reduce the risk that developers will add this attribute for platforms where it is not needed, removing useful profiling unnecessarily.

Something like:

```swift
#if hasFeature(Embedded)
@disableSanitizer(address)
#endif
func readsMMIO(_ p: UnsafePointer<UInt32>) -> UInt32 { p.pointee }

```

Overall though, this seems like a useful proposal.

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [September 23, 2026, 10:29pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/5 "2026-09-23T22:29:47Z")

</div>

The attribute seems to be more general than sanitizers already, and I wonder if we shouldn’t bow to that. The only problem is that the more general term is “instrumentation”, which is quite a mouthful even before you start negating anything. But it would be a better name for controlling instrumentation function-by-function in some way _other than_ just disabling it.

I don’t find the precedent of Clang using an attribute name to be very important.

---

<div class="post-metadata">

**Author:** ![James\_Dempsey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/james_dempsey/32/14336_2.png) [@James\_Dempsey](https://forums.swift.org/u/James_Dempsey)\
**Post date:** [September 24, 2026, 4:08pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/6 "2026-09-24T16:08:27Z")

</div>

> [@John\_McCall](#):
>
> The only problem is that the more general term is “instrumentation”, which is quite a mouthful

Perhaps `@instrument()` which can read a verb.

---

<div class="post-metadata">

**Author:** ![j-f1](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/j-f1/32/12287_2.png) [@j-f1](https://forums.swift.org/u/j-f1)\
**Post date:** [September 24, 2026, 4:38pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/7 "2026-09-24T16:38:03Z")

</div>

For grammatical comparison, [`@specialized`](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0460-specialized.md) shipped in 6.3.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [September 24, 2026, 4:40pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/8 "2026-09-24T16:40:43Z")

</div>

FWIW, the 'Swift'-ization most apt here is "noescape" → "nonescaping."  
By that analogy, this would be `@nonsanitizing`.

---

<div class="post-metadata">

**Author:** ![ndrewh](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ndrewh/32/46240_2.png) [@ndrewh](https://forums.swift.org/u/ndrewh)\
**Post date:** [September 27, 2026, 9:56pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/9 "2026-09-27T21:56:22Z")

</div>

> [@John\_McCall](#):
>
> The attribute seems to be more general than sanitizers already, and I wonder if we shouldn’t bow to that.

Would it make sense to have an `@instrumentation` attribute which takes an explicit list of instrumentation types to `enable:` or `disable:`?

For the existing supported sanitizers, it would probably make sense to only support explicitly disabling them for now (they should only be enabled at the driver-level):

```swift
@instrumentation(disable: [asan, tsan, memtagStack])

```

But perhaps other types of instrumentation would want to re-use this attribute as a per-function enablement mechanism (e.g. [XRay](https://llvm.org/docs/XRay.html)).

```swift
@instrumentation(enable: [xray])

```

This does seem to open the question of how a function with _enabled_ instrumentation would interact with inlining, but perhaps we can punt that decision until the first instrumentation type is added that wishes to use per-function enablement.

> [@xwu](#):
>
> FWIW, the 'Swift'-ization most apt here is "noescape" → "nonescaping."  
> By that analogy, this would be `@nonsanitizing`.

I find this odd, only because the verb "escape" is used to describe a specific behavior of a function (i.e. a closure argument either escapes a function or it doesn't), whereas "sanitize" describes a behavior of the compiler (i.e. a compiler can choose to sanitize a function, or not) and doesn't say anything about the function at all. To say a function is "nonsanitizing" sounds like it would be a statement about the function's behavior, but it's really just a directive to the compiler.

> [@j-f1](#):
>
> For grammatical comparison, [`@specialized`](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0460-specialized.md) shipped in 6.3.

I think `@instrumented` would be the analogue? If we wanted a single attribute for enabling/disabling instrumentation, perhaps we could do something like `@instrumented(with: [], without: [])`but I'm not sure that's Swift-like at all.

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [October 1, 2026, 5:39pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/10 "2026-10-01T17:39:48Z")

</div>

Hey folks,

The Language Steering Group has discussed this proposal. We are supportive of adding this attribute to Swift, but have requested some modifications:

- We felt, as did many community members who reviewed the proposal, that the spelling `@noSanitize` was not the right fit for Swift. Our preference among the spellings suggested in the review thread was `@instrumentation(disable: names...)`. Likewise, the compiler condition has been renamed to `#if instrumentation(sanitizerName)`.

- To ensure that the names of sanitizers passed to this attribute are consistent and predictable, we would like to apply an algorithmic transformation based on the names of the sanitizers as they are passed on the command line. The name used in an attribute is the lowerCamelCase form of that flag value: `address`, `thread`, and `memtagStack`. (`coverage` remains unchanged as it is not controlled by the same flag set.)

- For consistency with SE-0537 (function sections), we believe that the effects of the `@instrumentation` flag _should_ propagate to nested closures. This means that there should be an escape hatch to return to the original behavior if needed. For that, we can again follow SE-0537's precedent and spell this as `@instrumentation(default)`.

The author has made these changes to the proposal ([view the diff](https://github.com/swiftlang/swift-evolution/pull/3522/changes)).

We would like to give the community another chance to comment on these changes, so we are extending the review for one week ( **until October 8th** ).

Thank you!  
—Tony Allevato, review manager

---

<div class="post-metadata">

**Author:** ![owenv](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/owenv/32/6137_2.png) [@owenv](https://forums.swift.org/u/owenv)\
**Post date:** [October 1, 2026, 5:54pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/11 "2026-10-01T17:54:12Z")

</div>

Does the new nesting behavior also apply to nested function declarations, or just closures?

```swift
@instrumentation(disable: address)
func outer() {
    func inner() {
      // Is inner instrumented?
    }
}

```

There are also rarely used patterns using nested types like the following which have inconsistently handled attributes in the past.

```swift
@instrumentation(disable: address)
func outer() {
  struct Nested {
    func inner() {
      // Is inner instrumented?
    }
  }
}

```

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [October 1, 2026, 5:57pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/12 "2026-10-01T17:57:36Z")

</div>

Since the intent is to mirror the behavior of `@section` in SE-0537, we should ensure that it applies in the same scenarios [as described here, where it is "inferred on accessors, closures, and local functions"](https://github.com/swiftlang/swift-evolution/pull/3522/changes).

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [October 5, 2026, 10:33pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/13 "2026-10-05T22:33:10Z")

</div>

Hi all,

I'm concerned that the interaction between the `@noSanitize` attribute and the `#if sanitized` compile-time conditional. Consider this code:

```swift
@noSanitize(address)
func f() {
#if sanitized(address)
#error("shouldn't get here")
#endif
}

```

Does this produce an error when building the module with Address Sanitizer? I would like the answer to be "no", because the code in `f` never has Address Sanitizer enabled due to `@noSanitize(address)`.

However, that's not really what falls out of the implementation. The `#if` evaluation only understands module-scope information, so it's going to produce an error. That seems surprising and incorrect.

Availability has a model that might make more sense here. The `@available` attribute provides availability, and within that declaration that availability holds. We have the `if #available(...)` formulation that is correctly context-sensitive.

I'm inclined to say that we shouldn't have the `#if sanitized(...)` capability at all if it can't be context-sensitive. The justification for having `#if sanitized(...)` seems to be entirely about inlining, so perhaps we won't need it if we address inlining some other way.

Doug

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [October 5, 2026, 10:43pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/14 "2026-10-05T22:43:28Z")

</div>

I generally agree. One difficulty, though, is that `#if` can be used in positions that `if #` cannot, some of which have dependency problems for resolving the contextually-correct answer — in particular, attribute lists. There might be a reasonable solution to that, though.

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [October 14, 2026, 7:40pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/15 "2026-10-14T19:40:43Z")

</div>

Hey folks,

The Language Steering Group discussed this proposal again and share Doug's concerns about whether `#if instrumentation(...)` could be misinterpreted when nested inside a lexical context where `@instrumentation(...)` had been applied.

The proposal as written states that `#if instrumentation(...)` always evaluates to the module-wide setting—that is, based on the flags passed to the compiler invocation. The LSG believes that it might be nice for something like `#if instrumentation(...)` to consider lexical context, but there is no precedent in Swift today for an `#if` clause to be evaluated that way and such a change would require significant design that is beyond the scope of this proposal.

We asked the proposal author to consider other names/shapes for the compiler condition that clarify that it is a module-wide value. The author has addressed this by [updating](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0550-nosanitize-attribute.md) the proposal to rename the condition to `#if moduleInstrumentation(...)`, which explicitly makes the scope clear. The diff for this specific change can be viewed [here](https://github.com/swiftlang/swift-evolution/commit/a3ec6964d00512eed1a0ef31a99bc723c8b97307).

We are extending the review again until **October 20th** to give the community an opportunity to consider this change.

Thank you!  
—Tony Allevato, review manager

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [October 23, 2026, 8:39pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/16 "2026-10-23T20:39:55Z")

</div>

The Language Steering Group has [accepted this proposal](https://forums.swift.org/t/accepted-se-0550-instrumentation-attribute-for-functions-was-nosanitize-attribute-for-functions/90225).

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [October 23, 2026, 11:20pm UTC](https://forums.swift.org/t/se-0550-nosanitize-attribute-for-functions/89593/17 "2026-10-23T23:20:31Z")

</div>

Closed on October 23, 2026, 11:20pm UTC