# Fun One Liners

**URL:** https://discourse.julialang.org/t/fun-one-liners/28352
**Category:** General Usage
**Created:** [September 3, 2019, 11:13pm UTC](https://discourse.julialang.org/t/fun-one-liners/28352 "2019-09-03T23:13:18Z")
**Posts on this page:** 1
**Showing post:** 73

<div class="post-metadata">

### Author: ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)
#### Post date: [September 17, 2019, 12:37am UTC](https://discourse.julialang.org/t/fun-one-liners/28352/73 "2019-09-17T00:37:36Z")

</div>

> [@chakravala](#):
>
> No, but `@pure` is not very well documented

I wouldn’t call this “not very well documented” [https://docs.julialang.org/en/latest/base/base/#Base.@pure](https://docs.julialang.org/en/latest/base/base/#Base.@pure) :

> `@pure` gives the compiler a hint for the definition of a pure function, helping for type inference.
> 
> A pure function can only depend on immutable information. This also means a `@pure` function cannot use any global mutable state, including generic functions. Calls to generic functions depend on method tables which are mutable global state. Use with caution, incorrect `@pure` annotation of a function may introduce hard to identify bugs. Double check for calls to generic functions. This macro is intended for internal compiler use and may be subject to changes.

In particular, I think it is very clear that you can’t use generic functions inside `@pure` functions. Please notice that this is incompatible with your usage:

> [@Marking more standard library methods as pure to enable LLVM optimizations?](https://discourse.julialang.org/t/marking-more-standard-library-methods-as-pure-to-enable-llvm-optimizations/28732/8):
>
> ```julia
> module Grassmann
> @pure binomial(n::Int,k::Int) = Base.binomial(n,k)
> end
> 
> ```
> 
> This replaces the `Base.binomial` method with a local method that is pure.

I think it’s OK to depend on implementation details in some private code or maybe even in public code if you are aware that is an implementation detail and hence cannot rely on the semver promises. For example, [ForwardDiff.jl uses `Threads.atomic_add!` inside `@generated` generator](https://github.com/JuliaDiff/ForwardDiff.jl/blob/c374b69f47095aef60a5486065ddc6fe29c32e9f/src/config.jl#L12-L14) which also is documented that it must be pure. Also, there are (many?) packages using `@generated` to hoist out argument checking to compile time. Since `throw` is a side-effect, this is arguably not a valid use case. CUDAnative.jl is mentioning that it can be a real trouble if you want to use it with GPU: [https://juliagpu.gitlab.io/CUDAnative.jl/man/hacking/#Generated-functions-1](https://juliagpu.gitlab.io/CUDAnative.jl/man/hacking/#Generated-functions-1)

@NHDaly’s JuliaCon talk is a great summary of the current status on this topic and explaining why you can’t use `@pure` or `@generated` in this way safely:

[![](https://global.discourse-cdn.com/julialang/original/3X/2/a/2aa19e0feab4b32c9496c2aeae55dfaa4d19fac2.jpeg "JuliaCon 2019 | If Runtime isn't Funtime: Controlling Compile-time Execution | Nathan Daly") ](https://www.youtube.com/watch?v=JCFej--XER0)

Personally, I often just lift values to type domain as soon as possible and compute things using recursion.

---

_[View the full topic](https://discourse.julialang.org/t/fun-one-liners/28352)._