# @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:** 20\ **Page:** 1
**Author:** ![jmjauer](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jmjauer/32/15911_2.png) [@jmjauer](https://forums.swift.org/u/jmjauer)\ **Post date:** [March 29, 2020, 12:57pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/1 "2020-03-29T12:57:21Z")
Swift lacks for semantic information if a function is free of side effects or not. Adding a `@pure` function attribute would give compile time information about a function being free of side effects. For a `@pure` function, the compiler would need to verify that the function is free of side effects (wich would be possible because of the `@pure` annotation of other functions). The current api for the map function for collections is: `func map(_ transform: (Element) throws -> T) rethrows -> [T]` Adding @pure would look like this: `func map(_ transform: @pure (Element) throws -> T) rethrows -> [T]` Benefits: - api information expressed with language semantics - possible compile time optimizations ---
**Author:** ![ctxppc](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ctxppc/32/1164_2.png) [@ctxppc](https://forums.swift.org/u/ctxppc)\ **Post date:** [March 29, 2020, 1:36pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/2 "2020-03-29T13:36:56Z")
I like any proposal that introduces more referential transparency into programs so a big +1 from me! However, my primary concern with an effects system is that some side-effects are treated as non-side-effects by us, and I’m thinking primarily of logging. For example, a map invocation invoking any method that does some logging (even conditionally as part of an error routine) would be illegal or would require an opt-out from the pure annotation. We’d probably need to work out an opt-out mechanism but without introducing heavy syntax. ---
**Author:** ![jmjauer](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jmjauer/32/15911_2.png) [@jmjauer](https://forums.swift.org/u/jmjauer)\ **Post date:** [March 29, 2020, 1:54pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/3 "2020-03-29T13:54:24Z")
I agree that there should be some exceptions, but especially for logging I do not see the need. Logging should log effects and not pure calculations. For debugging there would need to be some exception - but that could be really easy: At some level, the `@pure` annotation has to start - some primitives has to be annotated without the compiler check. Some none pure build in functions could use `@pure` on purpose, for example `print`. ---
**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… ---
**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:08pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/5 "2020-03-29T14:08:42Z")
> [@jmjauer](#): > > The current api for the map function for collections is: > > `func map(_ transform: (Element) throws -> T) rethrows -> [T]` > > Adding @pure would look like this: > > `func map(_ transform: @pure (Element) throws -> T) rethrows -> [T]` As an aside, although `map` in Swift is inspired by operations of that name in functional languages, it is explicitly not limited to ‘pure’ transforms. Nor would it be possible to make it so, given ABI stability guarantees. What would have been possible (and might still be possible) is for `map` to be “re-pure,” in the sense that it is pure if the transform is pure. I would urge you to spend some time reading through the multiple preceding threads to see the extensive discussion already conducted on this topic. There is no need to start over from scratch; what would be helpful is if you could summarize what you read in those threads so that we can avoid repeating the same things over and over but instead make progress! ---
**Author:** ![michelf](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michelf/32/1180_2.png) [@michelf](https://forums.swift.org/u/michelf)\ **Post date:** [March 29, 2020, 2:11pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/6 "2020-03-29T14:11:58Z")
My earlier exploration of this topic: [Exploratory proposals: Pure & Concurrent](https://forums.swift.org/t/exploratory-proposals-pure-concurrent/8085) ---
**Author:** ![jmjauer](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jmjauer/32/15911_2.png) [@jmjauer](https://forums.swift.org/u/jmjauer)\ **Post date:** [March 29, 2020, 2:15pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/7 "2020-03-29T14:15:34Z")
I agree, I should have spent some time to check if other pitches existed before. I will read them and summarize them. ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [March 29, 2020, 2:39pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/8 "2020-03-29T14:39:27Z")
> [@michelf](#): > > My earlier exploration of this topic: [Exploratory proposals: Pure & Concurrent](https://forums.swift.org/t/exploratory-proposals-pure-concurrent/8085) I also spent some time exploring this topic: [Value semantics and pure functions: referential transparency for Swift](https://gist.github.com/anandabits/79156f0fdbd1d9b616a6be69f312cdf2). ---
**Author:** ![stephencelis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stephencelis/32/2675_2.png) [@stephencelis](https://forums.swift.org/u/stephencelis)\ **Post date:** [March 29, 2020, 3:24pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/9 "2020-03-29T15:24:50Z")
> [@xwu](#): > > it is explicitly not limited to ‘pure’ transforms Just curious if you have a citation here? I had just assumed it is _implicitly_ not limited to pure transformations because Swift doesn't have any ability to do so (though `@pure` would aid in this). ---
**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, 5:11pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/10 "2020-03-29T17:11:47Z")
You and I have had this exact conversation before: > [@Add \`filter\` and \`ifSome(then:)\` to Optional](https://forums.swift.org/t/add-filter-and-ifsome-then-to-optional/8143/12): > > It's true that map is borrowed from functional programming, but Swift has no concept of 'pure' functions and has never made such a requirement for map. The Swift Programming Language itself has (or at least, one of its editions once had) an example of map(print), so I think it's fair to say that such usage is 'idiomatic' Swift. ---
**Author:** ![mattrips](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattrips/32/4079_2.png) [@mattrips](https://forums.swift.org/u/mattrips)\ **Post date:** [March 31, 2020, 4:52am UTC](https://forums.swift.org/t/pure-function-attribute/34907/11 "2020-03-31T04:52:23Z")
> [@xwu](#): > > You and I have had this exact conversation before: Ha! My spouse does this to me all the time, but without benefit of an electronic archive and search function. (sorry for the interruption; couldn’t help myself) ---
**Author:** ![ishan](https://avatars.discourse-cdn.com/v4/letter/i/3da27b/32.png) [@ishan](https://forums.swift.org/u/ishan)\ **Post date:** [April 1, 2020, 2:54am UTC](https://forums.swift.org/t/pure-function-attribute/34907/12 "2020-04-01T02:54:51Z")
Though the proposal sounds interesting but my only concern is how is it going to make sure that the functions being passed are pure or the functions which have @pure annotations are actually pure. What if there are side effects due to multithreaded environment? Is it possible to create A generic annotation that can test the function for all kinds of side effects without knowing the different use cases of the functions that users are going to use? ---
**Author:** ![jmjauer](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jmjauer/32/15911_2.png) [@jmjauer](https://forums.swift.org/u/jmjauer)\ **Post date:** [April 1, 2020, 2:06pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/13 "2020-04-01T14:06:29Z")
Hi Ishan, first we need to think about what pure means. Producing side effects is unavoidable at same level. When we talk about pure functions we mean mathematical functions like `f(x) = y`. But even this type of function produces side effect: The computer changes memory to execute a function like this - it changes the state of something. Executing the function twice produces 2 different states in you computers memory. The good news is, we do not care about these types of side effects. They do not affect the domain we want to avoid side effects for. So our definition could be: 1. The only purpose of a pure function is to calculate its output. 2. The output only depends on its input. 3. The same input always produces the same output. According to this, the compiler would need to check if a `@pure` function only executes code that is pure. Since this is a recursive definition, it needs to start somewhere. At some level, we just need to tell the compiler: this is pure, don't check it. For example, the typical math operators (+, -, \*, /) are pure and could be annotated with an unchecked `@pure`. After that every other `@pure` function could use these and the compiler could verify the pureness of these functions. Greetings, Johannes ---
**Author:** ![sveinhal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sveinhal/32/3992_2.png) [@sveinhal](https://forums.swift.org/u/sveinhal)\ **Post date:** [April 2, 2020, 5:37am UTC](https://forums.swift.org/t/pure-function-attribute/34907/14 "2020-04-02T05:37:54Z")
In my opinion, pure functions in Swift should: - not read or write any global or static mutable state, or any other state not passed explicitly as input arguments - not call functions that are not also pure - not be overridden by an impure function (but could themselves override impure functions) - not perform I/O I guess they could mutate inout parameters, allocate memory, throw, mutate reference types that are explicitly passed as arguments, call function-private inner functions, even if they’re impure (since their context is pure), etc. ---
**Author:** ![sveinhal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sveinhal/32/3992_2.png) [@sveinhal](https://forums.swift.org/u/sveinhal)\ **Post date:** [April 2, 2020, 5:43am UTC](https://forums.swift.org/t/pure-function-attribute/34907/15 "2020-04-02T05:43:55Z")
In the strictest sense, a pure function couldn’t even print debug messages, read or write the floating point mode flags (even if the flags are reset before the function exits), etc. I think we should opt for a somewhat laxer definition than that. ---
**Author:** ![mattpolzin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mattpolzin/32/6041_2.png) [@mattpolzin](https://forums.swift.org/u/mattpolzin)\ **Post date:** [April 3, 2020, 5:31pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/16 "2020-04-03T17:31:22Z")
> [@sveinhal](#): > > not read or write any global or static mutable state, or any other state not passed explicitly as input arguments Although I have not fully thought through the following, I think there’s an opportunity here for Swift purity to include non mutating methods on value value types — these could fit the above definition in every way except for the fact that `self` is an implicit argument to the function (generally, I know you can pass that argument explicitly but you don’t explicitly define it as an argument). [edit] I do _not_ mean to say that being non-mutating is enough to state purity in-and-of-itself. I just mean I’m not sure being a method needs to exclude a function from consideration. ---
**Author:** ![viktorcode](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/viktorcode/32/7737_2.png) [@viktorcode](https://forums.swift.org/u/viktorcode)\ **Post date:** [April 3, 2020, 7:18pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/17 "2020-04-03T19:18:30Z")
I very much want explicit support for purity, so this have +1 from me. I’m not sure I'm on board with `@pure` attribute. In a well structured data oriented code the majority of functions will end up being pure. This will add a lot of boilerplate purity declarations. So, there should be something else. ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [April 3, 2020, 7:21pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/18 "2020-04-03T19:21:04Z")
@Joe_Groff has talked about introducing a new `=>` arrow to indicate purity without the boilerplate. ---
**Author:** ![clayellis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/clayellis/32/43646_2.png) [@clayellis](https://forums.swift.org/u/clayellis)\ **Post date:** [April 3, 2020, 8:15pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/19 "2020-04-03T20:15:03Z")
Should there be any indication at the call site that you're invoking a pure function? (Apologies if this has already been discussed in one of the other threads.) ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [April 3, 2020, 8:24pm UTC](https://forums.swift.org/t/pure-function-attribute/34907/20 "2020-04-03T20:24:36Z")
No, there is no reason for that. The point is to disallow pure functions from calling impure functions. [Next page](https://forums.swift.org/t/pure-function-attribute/34907.md?page=2)