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.
Just as a counterbalance, improper
@pureannotations 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.
Until the unexported @pure is renamed @hyperpure and a new more well groomed @pure is made … things are as they are.