What would be an example? Iterator adaptors are already monomorphized and expanded into imperative code. All closures are inlined. Attributes on inlined functions, including purity declarations, are both unused and useless. The point of function effect specification is to be able to analyze function calls without looking (recursively) into its body, but the bodies of inlined functions are already transparent to the optimizer.
And to repeat, my objection is that purity in the context of Rust seems too restrictive to include much practically useful code. That's not the case in Haskell, which simply ignores some of the side effects.
Anything that short-circuits. If we know that closures are pure than we can call them more often than promised by the API because we'll know that the distinction is not observable. Then we can for example fetch them in chunks of 4, let autovectorization do its job and recover the result as-if it short-circuited by examining the lanes more closely after dropping out of the vectorized loop.
Among the simplest cases is iter.all(f) could put items in [T; 4], call f 4 times, put the results in a [bool as u32; 4] and check for == [1u32; 4] or whatever pleases the optimizer.
This could also be extended to other final methods like cmp, eq and also adapters map, filter, take_while, ....
I'm not talking about hint attributes for llvm. I'm talking about having a purity property in the type system (either via effects or a is_pure<T>() hint function like needs_drop<T>()) and performing the optimizations in the library.
That is not considered observable behavior by the abstract machine or by whatever leeway we give ourselves in std.
Yeah, we'd have to sprinkle some marker traits over the iterator pipeline to figure out which ones we can and can't optimize this way. Same as with other iterator optimizations we already have.
#[pure]
fn foo(){
let a: Box<usize> = Box::new(0);
println!("{:?}",a);
}
rustc need to valid the attribute pure for the function, right?
And how to implement to pure checking?
But if we have a full pure checking in rustc, the attribute #[pure] seems useless.
Just let rustc/llvm to check it.
I think that, for the purposes of optimization, it'd be enough to add a "cheap" (or "idempotent") attribute, marking that it's okay to call a function repeatedly, or in advance... and to just trust the user on that. It can only lead to logic errors, which would be on the user for misusing the attribute.