Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

OK, fair enough, but it still seems like the rust compiler has enough information to determine whether something is a pure function. It knows whether global or enclosed variables are present and it knows if any of the methods it calls have an &mut ref, which I think is needed even for IO reading


Yeah, I think the compiler has enough information to do that, in principle. But there is another problem: Rust has the design principle that every language-enforced invariant should be clear just from the function signature. This has at least two benefits: the compiler doesn't have to reason about the code invariants "globally", which might slow and hard to optimize, and the APIs are clearer and the user doesn't have to know implementation details to reason about them.

If there's going to be some concept of purity, according to the same principle, it'd be something that one could know just by looking at the function signatures.


Something could call into FFI. Or whatever.

The Rust compiler tries not to talk of function kinds past the function boundary as a design principle^. So while the compiler can do a transitive search down all function calls and ensure there's no trickery, Rust doesn't want to do things like that. Inference should not extend past a function.

Introducing a `pure` or `const` keyword to be applied on fns would work, that way the pureness of a function can be determined without recursing into its contents. We've had some proposals for the latter, but no full implementations or rfcs yet IIRC. It might happen.

^I think it's a design principle, at least.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: