If you don't mind changing ntimes to not return a closure:
fn ntimes(f: &fn(T) -> T, times: uint, x: T) -> T {
match times {
0u => x,
_ => ntimes(|x| f(x), times - 1u, f(x))
}
}
fn main() {
println(format!("{:d}", ntimes(|k| k*2, 2u, 3)));
}
__
On Sun, Oct 27, 2013 at 9:41 AM, Patrick Walton wrote:
> But
> by the time the closure is invoked, `f` won't exist, because the activation
> record for the `ntimes` function won't exist anymore.
I tried tying the lifetime of `f` to the lifetime of the returned
function by making them both &'a...,
The example on
https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-09-10#fate-of-const
seems sensible at first, but the rule it suggests would not be safe.
Allowing one closure to take &mut while another takes &const would
create a data race if the two closures are executed in parallel.
task
Should functions default to pure?
* With
http://smallcultfollowing.com/babysteps/blog/2012/10/12/extending-the-definition-of-purity-in-rust/
I think most functions will be able to be pure.
* Would avoid the problem of forgetting to mark a function as pure,
causing pain for a caller. (Or worse,
A warning for unused pattern bindings would help:
https://github.com/mozilla/rust/issues/941
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
My preference is to remove null termination:
* I'm guessing most strings aren't passed to C. (What are the most
common C string calls in rustc?)
* C functions that scan for null are inefficient, so they're even more
likely to be replaced with Rust equivalents than other C functions.
* Null termi
I marked interner::get as "pure" on the basis that once it succeeds,
it always succeeds and always returns the same thing. I hope this is
reasonable.
The key typestate guarantee still holds: once you've checked it, you
can rely on it. But you can't hoist the check arbitrarily far like you
can with
> Agreed it's hard to replicate. What I'm getting at is that at present, it
> seems they're rather hard to *support* everywhere, period. How useful are
> tail calls if they only work in "very restricted" circumstances? It's a bit
> of an offense against language orthogonality and compositionality,
