I think there is a bug in the region parameterization inference that causes it to mistakenly infer that the trait map (in this case) is region parametrized. I've seen such bugs before but since the plan is to remove region parameterization inference in favor of explicit declarations I haven't bothered to isolate it. By the way I do hope to land those changes soon.
If this is blocking you let me know and I'm sure we can come up with a work around. Niko (Sent from a cramped, unreliable keyboard) -------- Original message -------- Subject: [rust-dev] ptr to trait with fun that returns borrowed ptr can't be put in another struct? From: John Clements <[email protected]> To: [email protected] CC: It appears that if a trait has a function that returns a borrowed pointer with lifetime self (e.g. Map), then pointers to values with that trait can't be stored in other structures. Here's the example I'm thinking of: pub trait MyMap { fn find(&self) -> &self/uint; } type MyTy = MyMap; pub struct AStruct { a : ~MyTy } pub fn new(init: ~MyTy) -> AStruct { AStruct {a:init} } this signals the error(s): oiseau:/tmp clements> rustc --test foo.rs foo.rs:19:4: 19:11 error: cannot infer an appropriate lifetime due to conflicting requirements foo.rs:19 AStruct {a:init} ^~~~~~~ foo.rs:18:35: 20:1 note: first, the lifetime cannot outlive the anonymous lifetime #1 defined on the block at 18:35... foo.rs:18 pub fn new(init: ~MyTy) -> AStruct { foo.rs:19 AStruct {a:init} foo.rs:20 } foo.rs:19:15: 19:19 note: ...due to the following expression foo.rs:19 AStruct {a:init} ^~~~ foo.rs:18:35: 20:1 note: but, the lifetime must be valid for the anonymous lifetime #2 defined on the block at 18:35... foo.rs:18 pub fn new(init: ~MyTy) -> AStruct { foo.rs:19 AStruct {a:init} foo.rs:20 } foo.rs:19:4: 19:11 note: ...due to the following expression foo.rs:19 AStruct {a:init} ^~~~~~~ error: aborting due to previous error Changing the return type of find() to be simply 'uint' makes the problem go away. Is this correct behavior? If so, is there an obvious workaround? Without understanding the problem, it's hard to see what the workaround would be. Thanks! John _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
