4 ms·

I've actually got that error with 1.15 as well. Or by "recently" you meant "on the nightly"? I updated hyper to 0.10.4, but the issue is still there. I will ch

by ainar-g 10y ago

I've actually got that error with 1.15 as well. Or by "recently" you meant "on the nightly"? I updated hyper to 0.10.4, but the issue is still there. I will check your example app out (thanks for that!) but the problem in my code still remains and I hate the fact that I can't understand what's going on. That might be my biggest issue with Rust compared to Go. Something doesn't match and I don't know how to find the issue without going to IRC or /r/rust; with Go I've never had an issue that wasn't resolved by carefully reading the language/library docs or StackOverflow.

steveklabnik 10y ago
> Or by "recently" you meant "on the nightly"? Yeah, it was removed literally last week, so it hasn't made it into a release yet. Without knowing what version of postgres you're using, I can't _totally_ get this to compile, it complains that SslMode isn't there. But, I did fix your issue: fn handle<'a, 'b>(&self, req: server::Request<'a, 'b>, mut res: server::Response<'a>) This compiles for me. The issue here is lifetime elision. http://rust-lang.github.io/book/ch10-03-lifetime-syntax.html#Lifetime-Elision http://rust-lang.github.io/book/ch10-03-lifetime-syntax.html... Specifically, rule 3: > If there are multiple input lifetime parameters, but one of them is &self or &mut self, then the lifetime of self is the lifetime assigned to all output lifetime parameters. So here, Request and Response both have lifetime parameters. This means that your original signature is the same as fn handle<'a>(&'a self, req: server::Request<'a, 'a>, mut res: server::Response<'a>) Which says "when I call handle, I borrow myself for as long as request and response are borrowed." That won't work; user_index_handler only lives for the duration of the call. The fixed signature says fn handle<'a, 'b>(&self, req: server::Request<'a, 'b>, mut res: server::Response<'a>) "When I call handle, the request and response share one lifetime, and request also has another lifetime." You're no longer connecting &self to the request and response, and so things are just fine. Honestly, this isn't the simplest signature; it's not surprising that you got stuck. This is also what people mean when they say "I fought with the borrow checker for a while, but then got over it", as it took me less time to fix this error than to write out this comment explaining how to! But until you've got that intuition and understanding, it can feel like hitting a brick wall.
- ainar-g 10y ago
  Wow, thanks for the reply. I copied the signature directly from your post and... it didn't work. I still got `user_index_handler` does not live long enough. But! If I replace impl server::Handler for UserIndexHandler with impl UserIndexHandler it does compile. Removing the trait impl was another thing recommended by the Arc guy at work, he didn't know how or why it worked. Here is the code that doesn't compile with updated Postgres: https://is.gd/fjYDIG https://is.gd/fjYDIG. Which brings me to a question, how does implementing a trait prevent this code from compiling? Sorry for comparing apples to oranges again, but in Go implementing an interface is an invisible operation, that doesn't affect compilation. What's different with Rust?
  - steveklabnik 10y ago
    I am about to go into two hours of meetings so this will have to be quick. The issue is, because this is a trait, you must conform to its signature. Which is here: https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.html https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... and specifically https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.html#tymethod.handle https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... So yeah, my idea won't work, because those types conflict. > Removing the trait impl was another thing recommended by the Arc guy at work, he didn't know how or why it worked. I'm surprised it works on first glance, as I was assuming that you were implementing the trait for a reason, not just because. If you don't need the trait, then yeah, it's much easier. > What's different with Rust? See my StackExchange link elsewhere in the thread for a summary. I'll maybe poke at this after my meetings, or maybe tomorrow. We'll see how amped I am for coding after all that ;)
    - ainar-g 10y ago
      Okay, thank you again for your time!
      - steveklabnik 10y ago
        Ah! I understand now. Handlers aren't meant to be nested like this. That is, it's always going to break this way, because the handler needs to live as long as the request and response, so creating a sub-handler is not ever going to live long enough. So yes, the solution is to not implement Handler for your UserIndexHandler; then you can just call it. I bet there's something larger you could do as well, but I don't have enough experience with this interface to give good advice. Hyper's undergoing a huge docs drive for 0.11; I'm sure that'll help.

by ainar-g 10y ago

steveklabnik 10y ago

> Or by "recently" you meant "on the nightly"? Yeah, it was removed literally last week, so it hasn't made it into a release yet. Without knowing what version of postgres you're using, I can't _totally_ get this to compile, it complains that SslMode isn't there. But, I did fix your issue: fn handle<'a, 'b>(&self, req: server::Request<'a, 'b>, mut res: server::Response<'a>) This compiles for me. The issue here is lifetime elision. http://rust-lang.github.io/book/ch10-03-lifetime-syntax.html#Lifetime-Elision http://rust-lang.github.io/book/ch10-03-lifetime-syntax.html... Specifically, rule 3: > If there are multiple input lifetime parameters, but one of them is &self or &mut self, then the lifetime of self is the lifetime assigned to all output lifetime parameters. So here, Request and Response both have lifetime parameters. This means that your original signature is the same as fn handle<'a>(&'a self, req: server::Request<'a, 'a>, mut res: server::Response<'a>) Which says "when I call handle, I borrow myself for as long as request and response are borrowed." That won't work; user_index_handler only lives for the duration of the call. The fixed signature says fn handle<'a, 'b>(&self, req: server::Request<'a, 'b>, mut res: server::Response<'a>) "When I call handle, the request and response share one lifetime, and request also has another lifetime." You're no longer connecting &self to the request and response, and so things are just fine. Honestly, this isn't the simplest signature; it's not surprising that you got stuck. This is also what people mean when they say "I fought with the borrow checker for a while, but then got over it", as it took me less time to fix this error than to write out this comment explaining how to! But until you've got that intuition and understanding, it can feel like hitting a brick wall.

ainar-g 10y ago
Wow, thanks for the reply. I copied the signature directly from your post and... it didn't work. I still got `user_index_handler` does not live long enough. But! If I replace impl server::Handler for UserIndexHandler with impl UserIndexHandler it does compile. Removing the trait impl was another thing recommended by the Arc guy at work, he didn't know how or why it worked. Here is the code that doesn't compile with updated Postgres: https://is.gd/fjYDIG https://is.gd/fjYDIG. Which brings me to a question, how does implementing a trait prevent this code from compiling? Sorry for comparing apples to oranges again, but in Go implementing an interface is an invisible operation, that doesn't affect compilation. What's different with Rust?
- steveklabnik 10y ago
  I am about to go into two hours of meetings so this will have to be quick. The issue is, because this is a trait, you must conform to its signature. Which is here: https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.html https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... and specifically https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.html#tymethod.handle https://hyper.rs/hyper/v0.10.0/hyper/server/trait.Handler.ht... So yeah, my idea won't work, because those types conflict. > Removing the trait impl was another thing recommended by the Arc guy at work, he didn't know how or why it worked. I'm surprised it works on first glance, as I was assuming that you were implementing the trait for a reason, not just because. If you don't need the trait, then yeah, it's much easier. > What's different with Rust? See my StackExchange link elsewhere in the thread for a summary. I'll maybe poke at this after my meetings, or maybe tomorrow. We'll see how amped I am for coding after all that ;)
  - ainar-g 10y ago
    Okay, thank you again for your time!
    - steveklabnik 10y ago
      Ah! I understand now. Handlers aren't meant to be nested like this. That is, it's always going to break this way, because the handler needs to live as long as the request and response, so creating a sub-handler is not ever going to live long enough. So yes, the solution is to not implement Handler for your UserIndexHandler; then you can just call it. I bet there's something larger you could do as well, but I don't have enough experience with this interface to give good advice. Hyper's undergoing a huge docs drive for 0.11; I'm sure that'll help.