These are chat archives for rust-lang/rust

18th
Jan 2016
Thomas Koehler
@Bastacyclop
Jan 18 2016 20:41
I don't understand this error
Igor
@target-san
Jan 18 2016 20:44
Since A depends on lifetime, you must also specify that lifetime in function signature, so it would properly know that func itself depends on that lifetime
fn do_stuff<'a>(f: Box<Fn(A<'a>) -> ()>) {
   f(A { x: &0 })
}
Thomas Koehler
@Bastacyclop
Jan 18 2016 20:46
&0 does not live long enough
:/
strange smiley
not really what I mean by ': /' x)
I just want f to use the object no longer than it's execution
Erik Hedvall
@Ogeon
Jan 18 2016 20:54
The problem is that you are creating a reference to a temporary number. It will not exist outside do_stuff, so the reference in A will point to garbage.
Thomas Koehler
@Bastacyclop
Jan 18 2016 20:54
I want fto use this reference when it is called but not after
so it shouldn't be a problem, should it ?
since when it is called this temporary number exists
fn do_stuff(f: Box<Fn(A) -> ()>) {
    let a = A { x: &0 };
    f(a) // You can temporary use `a`
    // But you can't keep it
}
Erik Hedvall
@Ogeon
Jan 18 2016 20:58
It is a problem, because 'a is longer than (or at least as long as) the scope of do_stuff, and you are saying that the reference must be valid for the entire scope of 'a. you should be able to do something like f: for<'a> Box<Fn(A<'a>) -> ()>, though. That will tell the compiler that 'a is only associated with f.
Thomas Koehler
@Bastacyclop
Jan 18 2016 20:59
says
Box is not a trait
Erik Hedvall
@Ogeon
Jan 18 2016 21:00
one moment...
Well, placing the for part can be a bit tricky... Here you go:
Igor
@target-san
Jan 18 2016 21:01
A very interesting problem I'd say.
Erik Hedvall
@Ogeon
Jan 18 2016 21:02
fn do_stuff(f: Box<for<'a> Fn(A<'a>) -> ()>) {
    f(A { x: &0 })
}
Thomas Koehler
@Bastacyclop
Jan 18 2016 21:04
Well, compiler still doesn't like it in the second case
But I don't really see why
Igor
@target-san
Jan 18 2016 21:07
It seems to be unable to infer type
Erik Hedvall
@Ogeon
Jan 18 2016 21:08
That's a different thing. It's some quirkiness in the type inference that seems to be caused by the fact that you are creating the closure in a separate variable
Thomas Koehler
@Bastacyclop
Jan 18 2016 21:10
And is there some way to explicitly indicate the required behavior ?
Erik Hedvall
@Ogeon
Jan 18 2016 22:44
Sorry, I had to rush away. let f = |_: A| {}; is a simple solution. I don't know of a more generic one off the top of my head.
Thomas Koehler
@Bastacyclop
Jan 18 2016 22:45
Thanks
Erik Hedvall
@Ogeon
Jan 18 2016 22:47
I think this is a known problem and there should be an issue for it, somewhere. I'm quite sure I bumped into it some time ago.