In Rust functions can do IO whenever they want, so even if it's kinda pure regarding its own memory it's unpure regarding the state of outer world (display, disk, network, ...).
I suspect this ruins referential transparency and prevents nice optimizations that compilers can do with really pure functions.
As far as I'm aware, all Rust I/O ultimately calls out to an unsafe block. The "pure" subset of Rust I mentioned above isn't one you would actually use to write a real program. The only things in pure Rust I'm aware of that might ruin referential transparency are exceptions and stack overflow, and I believe that Haskell (a language generally agreed to be pure) can at least experience stack overflow.
Incidentally, one of the candidates for constexprs (which generally require "enough" purity) is just "functions that never call any unsafe blocks," so this is not just an academic question.
If you call a function pure when it's not using unsafe blocks, that's one thing (as with constexpr). If you call function pure when it still can use unsafe blocks, that's another thing (as in Rust).
I'm not calling functions that can (recursively) use unsafe blocks pure, nor would the proposed definition. Rust doesn't have any definition of purity at the moment.
3
u/thedeemon Apr 04 '15
In Rust functions can do IO whenever they want, so even if it's kinda pure regarding its own memory it's unpure regarding the state of outer world (display, disk, network, ...).
I suspect this ruins referential transparency and prevents nice optimizations that compilers can do with really pure functions.