# @pure function attribute **URL:** \ **Category:** Pitches\ **Created:** [March 29, 2020, 12:57pm UTC](https://forums.swift.org/t/pure-function-attribute/34907 "2020-03-29T12:57:21Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [March 29, 2020, 2:05pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/4 "2020-03-29T14:05:42Z")
> [@Proposal proposal: @pure keyword](https://forums.swift.org/t/proposal-proposal-pure-keyword/993): > > I'd like to discuss adding a @pure keyword, and see what it requires and how possible it is to include. I'd like to use the annotation @pure on functions, methods and closures. This will allow us to make more guarantees about what a protocol does, and what it cannot do. It will also allow APIs like `.map` and `.forEach` to have a meaningful distinction. It could also allow for something like an assert to be removed as an optimisation with no side-effects in a release build. If something… > [@\[Proposal idea\] Support for pure functions](https://forums.swift.org/t/proposal-idea-support-for-pure-functions/1054): > > I'm moving the discussion from "Proposal proposal: @pure keyword" here and jumping in this time. 1. Pure means that the function always return the same value given the same arguments, and has no side effects (it purely computes a result from its inputs), making it possible for the compiler, or a cache, to reuse the result from a previous call. This is the simplest definition, and it provide strong guaranties. Let's call that "strongly pure". 2. Pure just mean that the function has no access t… > [@\[Pitch\] Support for pure functions. Part n + 1.](https://forums.swift.org/t/pitch-support-for-pure-functions-part-n-1/5197): > > # Pure Functions \* Proposal: [SE-NNNN]( [https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md\](https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md%5C)) \* Author(s): [TJ Usiyan]([https://github.com/griotspeak\](https://github.com/griotspeak%5C)) \* Status: \*\*Awaiting review\*\* \* Review manager: TBD ## Introduction Some functions are, essentially, only meant to be transformations of their input and–as such–do not and should not reference any variables other than those passed in. These same functions are not meant to have any effects other than the aforementi… > [@Idea: "pure" keyword for function signatures](https://forums.swift.org/t/idea-pure-keyword-for-function-signatures/6003): > > Writing functions without side effects is generally considered to result in less error-prone code. In Swift today, if you want to segment your code into pure and impure functions, you just have to police yourself, which is a very un-Swifty thing to have to do. This problem is compounded when working in teams, where someone else of course won’t know which of your functions are pure, and even if you leave a comment it’s not a guarantee they’ll know (or care) what “pure” means. So what about addin… > [@pure functions](https://forums.swift.org/t/pure-functions/6508/2): > > Splitting this out from the concurrency thread: In the manifesto you talk about restrictions on passing functions across an actor message. You didn’t discuss pure functions, presumably because Swift doesn’t have them yet. I imagine that if (hopefully when) Swift has compiler support for verifying pure functions these would also be safe to pass across an actor message. Is that correct? Correct. The proposal is specifically/intentionally designed to be light on type system additions, bu… --- _[View the full topic](https://forums.swift.org/t/pure-function-attribute/34907)._