lifetime

问题 I'm a new Rust user and I'm reading a book The Complete Rust Programming Reference Guide . In the book there is an example: fn main() { let mut a = String::from("testing"); let a_ref = &mut a; a_ref.push('!'); println!("{}", a); } The book states the code will generate an error. However, on my local machine, I can run it without any issue. Is this because I'm using a newer Rust compiler [ rustc 1.41.0-nightly (412f43ac5 2019-11-24) ] and the code doesn't work on older ones? I've read some

问题 I'm a new Rust user and I'm reading a book The Complete Rust Programming Reference Guide . In the book there is an example: fn main() { let mut a = String::from("testing"); let a_ref = &mut a; a_ref.push('!'); println!("{}", a); } The book states the code will generate an error. However, on my local machine, I can run it without any issue. Is this because I'm using a newer Rust compiler [ rustc 1.41.0-nightly (412f43ac5 2019-11-24) ] and the code doesn't work on older ones? I've read some

问题 Look at this code: #![feature(async_closure)] use std::future::Future; use std::pin::Pin; trait A<'a> { fn call(&'a self, data: &'a i32) -> Pin<Box<dyn 'a + Future<Output=()>>>; } impl <'a, F, Fut> A<'a> for F where Fut: 'a + Future<Output=()>, F: Fn(&'a i32) -> Fut { fn call(&'a self, data: &'a i32) -> Pin<Box<dyn 'a + Future<Output=()>>> { Box::pin(self(data)) } } async fn sample(_data: &i32) { } fn is_a(_: impl for<'a> A<'a>) { } fn main() { is_a(sample); is_a(async move |data: &i32| {

问题 I had a problem with generic traits in a larger context and try to size it down to this smaller problem. I want to have following function: fn count<I, S, T>(pattern: T, item:I) -> usize where I: Atom, S: Iterator<Item = I> T: Atoms<I, S>, { pattern.atoms().filter(|i| i == &item).count() } The function should be passed two arguments: pattern:Atoms<...> which has a factory method atoms returning an iterator of atoms item:Atom which is the item that should be counted in the iterator of atoms

问题 Look at this code: #![feature(async_closure)] use std::future::Future; use std::pin::Pin; trait A<'a> { fn call(&'a self, data: &'a i32) -> Pin<Box<dyn 'a + Future<Output=()>>>; } impl <'a, F, Fut> A<'a> for F where Fut: 'a + Future<Output=()>, F: Fn(&'a i32) -> Fut { fn call(&'a self, data: &'a i32) -> Pin<Box<dyn 'a + Future<Output=()>>> { Box::pin(self(data)) } } async fn sample(_data: &i32) { } fn is_a(_: impl for<'a> A<'a>) { } fn main() { is_a(sample); is_a(async move |data: &i32| {

问题 Given the implementation below, where essentially I have some collection of items that can be looked up via either a i32 id field or a string field. To be able to use either interchangeably, a trait "IntoKey" is used, and a match dispatches to the appropriate lookup map; this all works fine for my definition of get within the MapCollection impl: use std::collections::HashMap; use std::ops::Index; enum Key<'a> { I32Key(&'a i32), StringKey(&'a String), } trait IntoKey<'a> { fn into_key(&'a self

问题 In a project where custom Serde (1.0) serialization and deserialization methods are involved, I have relied on this test routine to check whether serializing an object and back would yield an equivalent object. // let o: T = ...; let buf: Vec<u8> = to_vec(&o).unwrap(); let o2: T = from_slice(&buf).unwrap(); assert_eq!(o, o2); Doing this inline works pretty well. My next step towards reusability was to make a function check_serde for this purpose. pub fn check_serde<T>(o: T) where T: Debug +

问题 In a project where custom Serde (1.0) serialization and deserialization methods are involved, I have relied on this test routine to check whether serializing an object and back would yield an equivalent object. // let o: T = ...; let buf: Vec<u8> = to_vec(&o).unwrap(); let o2: T = from_slice(&buf).unwrap(); assert_eq!(o, o2); Doing this inline works pretty well. My next step towards reusability was to make a function check_serde for this purpose. pub fn check_serde<T>(o: T) where T: Debug +

问题 CWG 1815 asked (with minor edits): struct A {}; struct B { A&& a = A{}; }; B b1; // #1 B b2{A{}}; // #2 B b3{}; // #3 [...] #2 is aggregate initialization, which binds B::a to the temporary in the initializer for b2 and thus extends its lifetime to that of b2 . #3 is aggregate initialization, but it is not clear whether the lifetime of the temporary in the non-static data member initializer for B::a should be lifetime-extended like #2 or not, like #1 . Per the Notes on that issue, at Issaquah

问题 I've tried to code like this several times: struct Foo { double const& f; Foo(double const& fx) : f(fx) { printf("%f %f\n", fx, this->f); // 125 125 } double GetF() const { return f; } }; int main() { Foo p(123.0 + 2.0); printf("%f\n", p.GetF()); // 0 return 0; } But it doesn't crash at all. I've also used valgrind to test the program but no error or warning occured. So, I assume that the compiler automatically generated a code directing the reference to another hidden variable. But I'm