# Suggestion: Fortran-like Keyword to Assert Function is Pure

**URL:** <https://discourse.julialang.org/t/suggestion-fortran-like-keyword-to-assert-function-is-pure/63047>\
**Category:** Internals & Design\
**Created:** [June 16, 2021, 8:34pm UTC](https://discourse.julialang.org/t/suggestion-fortran-like-keyword-to-assert-function-is-pure/63047 "2021-06-16T20:34:37Z")\
**Posts on this page:** 1\
**Showing post:** 45

<div class="post-metadata">

**Author:** ![mcabbott](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mcabbott/32/6603_2.png) [@mcabbott](https://discourse.julialang.org/u/mcabbott)\
**Post date:** [June 19, 2021, 1:01am UTC](https://discourse.julialang.org/t/suggestion-fortran-like-keyword-to-assert-function-is-pure/63047/45 "2021-06-19T01:01:57Z")

</div>

Some examples from broadcasting:

- In `f.(u) .+ g.(v')` (with u,v both length N vectors) you could perhaps do N evaluations of `f`, not `N^2`. But for something like `f(x) = x + rand()` this would change the answer, perhaps that’s impure for this purpose.

- In the gradient calculation for `f.(u)`, knowing that `f` does not close over other parameters would I think simplify how we handle it. Here `f(x) = y[1] + x` would be pure under Mason’s macro’s definition, but this needs something stronger.

Edit – it seems that `Base.issingletontype(typeof(f))` is a reasonable test for the 2nd case. The 1st seems to want a weaker definition than `@pure`’s, it’s not the method table that’s the concern. Whether this could be inferred, I don’t know. It could also be provided either when defining or when calling the function, like `@purecast f.(u) .+ g.(v')`.

---

_[View the full topic](https://discourse.julialang.org/t/suggestion-fortran-like-keyword-to-assert-function-is-pure/63047)._