Under certain assumptions, this may be part of a pure functional program. However by itself (e.g. as a library) it is not, because you have no guarantee that the input array stored in the "data" field is not being mutated by other code. In your actual code you probrably do have this guarantee.

One way to think about purity is in terms of "effects", e.g.

• reading from a mutable memory location
• writing to a mutable memory location
• writing to a file
• reading from a file
• reading the system time
• generating a random number
• failing to terminate

and so forth. If your program has no effects, then it is fair to call it pure. You can imagine annotating each function with the effects it causes, relative to the file handles and mutable objects it has access to.(Note, the Haskell IO monad provides one way to do this at a coarse granularity).

The use of effects doesn't automatically mean a program is impure. For example, if you can safely assume that no other code mutates the particular array stored in the "data" field then the above program is pure, despite the fact that it has "read" effects. Likewise, if you made a private copy of the array in your data structure then this particualr type is pure. The key thing is that the use of effects can't be effectively observed (forgive the pun)

[ Why do I say "effectively observed"? This is because there are ways of observing effects that we ignore in practice, e.g. counting CPU cycles, or clock time, or CPU temperature, or looking under-specified values such as object hash codes. ]

Thanks

Don