# Discussion on Base.@pure usage

**URL:** <https://discourse.julialang.org/t/discussion-on-base-pure-usage/56491>\
**Category:** Performance\
**Tags:** question\
**Created:** [March 4, 2021, 6:15pm UTC](https://discourse.julialang.org/t/discussion-on-base-pure-usage/56491 "2021-03-04T18:15:00Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![JeffreySarnoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffreysarnoff/32/1980_2.png) [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)\
**Post date:** [March 6, 2021, 11:48pm UTC](https://discourse.julialang.org/t/discussion-on-base-pure-usage/56491/10 "2021-03-06T23:48:26Z")

</div>

The confusion is not new news.

> Longer version: the sense of “purity” which is being used in Julia’s internals is much stronger than the intuitive notion of purity because Julia’s method tables are stateful, so almost any computation you can do is technically impure because it depends on the state of various method tables – e.g. for the `+` or `*` functions. These can be changed and indeed often are. Since there’s no way to seal these method tables (yet), there are very few situations in which no potential future method definition could change the result of a computation – you can redefine something as basic as integer addition, after all. (I don’t recommend it because your program will crash almost immediately, but you can do it.) I’ve proposed that we start referring to this extreme sense of purity as “hyperpure” or something like that, to avoid some of the confusion this terminology has been causing.

- [Is there a way to tell if a method is pure? - #3 by StefanKarpinski](https://discourse.julialang.org/t/is-there-a-way-to-tell-if-a-method-is-pure/2355/3)

> Just as a counterbalance, improper `@pure` annotations can introduce bugs. The optimizations it enables rely on an _extremely_ strict definition of pure. It really should be named something like `@hyperpure` . Some of the restrictions include:

- It must always return exactly ( `===` ) the same result for a given input. Watch out for mutable types. I think constant globals are okay, though.
- The function it’s used on cannot be further extended by other methods after it gets called.
- It cannot recurse.
- It’s undocumented and not exported (for good reason), but this means the complete list of preconditions is really only in a few people’s heads.

[@pure macro - #3 by mbauman](https://discourse.julialang.org/t/pure-macro/3871/3)

Until the unexported `@pure` is renamed `@hyperpure` and a new more well groomed `@pure` is made … things are as they are.

---

_[View the full topic](https://discourse.julialang.org/t/discussion-on-base-pure-usage/56491)._