lifetime

问题 This is a follow up question to: How to fix: cannot infer an appropriate lifetime for automatic coercion. I wonder why do these both structs differ in the way they are affected by lifetimes. Example 1 use http; pub struct Request<'a> { pub origin: &'a http::server::Request, } Example 2 use http; pub struct Response<'a, 'b> { pub origin: &'a mut http::server::ResponseWriter<'b>, } They look pretty much similar to me except that the second one holds a mutable reference whereas the first one

问题 Rust has an RFC related to non-lexical lifetimes which has been approved to be implemented in the language for a long time. Recently, Rust's support of this feature has improved a lot and is considered complete. My question is: what exactly is a non-lexical lifetime? 回答1: It's easiest to understand what non-lexical lifetimes are by understanding what lexical lifetimes are. In versions of Rust before non-lexical lifetimes are present, this code will fail: fn main() { let mut scores = vec![1, 2

问题 This may be a duplicate. I don't know. I couldn't understand the other answers well enough to know that. :) Rust version: rustc 1.0.0-nightly (b47aebe3f 2015-02-26) (built 2015-02-27) Basically, I'm passing a bool to this function that's supposed to build an iterator that filters one way for true and another way for false. Then it kind of craps itself because it doesn't know how to keep that boolean value handy, I guess. I don't know. There are actually multiple lifetime problems here, which

问题 I'm trying to build a simple pipeline-like functionality that executes each stage of the pipeline is separate threads and glues them all together with channel passing. Pipe::source(buffer) .pipe(|input, output| {...}) .pipe(|input, output| {...}) .sink(writer) I cannot for the life of me figure out the function signature for the pipe() function. Here's my code: use std::sync::mpsc::channel; use std::io::{ChanReader,ChanWriter}; use std::thread::Thread; struct Pipe { incoming: ChanReader }

问题 I am trying to figure out how to apply Rust lifetimes to add some compile-time enforcement to Erlang NIF modules. NIF modules are shared libraries normally written in C that provide extensions. A simplified prototype of the callback you would write in C looks like this: Handle my_nif_function(Heap *heap, Handle handle); You are provided a handle and a pointer to the heap that owns it. In your callback you may inspect the input handle, create more handles on the heap, and return one of them as

问题 Why doesn't Example 1 compile given that Example 2 compiles just fine? The only difference between the examples is that in Example 1 value is a function local variable, and in Example 2 value is an argument to the function. Example 1 #![feature(scoped)] use std::thread; use std::sync::atomic::{AtomicUsize, Ordering}; pub fn foo<F>() { let mut join_guards = Vec::new(); let value = AtomicUsize::new(0); for _ in 0..10 { join_guards.push(thread::scoped(|| { value.fetch_add(1, Ordering::SeqCst); }

问题 I'm writing very basic AI system in Rust. It's main components are: Action s, which can be implemented by library user, for specific use, Generic Context , which is passed to all actions, and only needs to live during the action execution, ActionsContainer , which "globally" stores all possible actions, System , which chooses the correct action and runs it. There are many systems, one for each agent. However, they share the same set of behaviours, so they all reference a common

问题 Here is a simplified example: struct Connection {} impl Connection { fn transaction(&mut self) -> Transaction { Transaction { conn: self } } } struct Transaction<'conn> { conn: &'conn Connection, } impl<'conn> Transaction<'conn> { fn commit(mut self) {} } fn main() { let mut db_conn = Connection {}; let mut trans = db_conn.transaction(); //1 let mut records_without_sync = 0_usize; const MAX_RECORDS_WITHOUT_SYNC: usize = 100; loop { //do something records_without_sync += 1; if records_without

问题 I am just starting to learn Rust. For this purpose I am rewriting my C++ project in Rust, but the biggest problems are lifetimes of closures and such. I created a absolute minimal scenario of my problem seen here and below: use std::sync::Arc; use std::cell::{RefCell, Cell}; struct Context { handler: RefCell<Option<Arc<Handler>>>, } impl Context { pub fn new() -> Arc<Context> { let context = Arc::new(Context{ handler: RefCell::new(None), }); let handler = Handler::new(context.clone()); (

问题 As suggested by the dynamic_reload crate's example, I collected Symbol s instead of extracting them every time, but Symbol requires a lifetime. Using a lifetime changes method signatures and breaks the compatibility with method DynamicReload::update . Is it a valid workaround to use std::mem::transmute to change Symbol 's lifetime to 'static ? extern crate dynamic_reload; use dynamic_reload::{DynamicReload, Lib, Symbol, Search, PlatformName, UpdateState}; use std::sync::Arc; use std::time: