3 ms·

What about making the object borrow from the closure? This can be accomplished by a method that consumes the object and returns the closure (which now owns the

What about making the object borrow from the closure? This can be accomplished by a method that consumes the object and returns the closure (which now owns the object), and a closure method's that borrows the object back from it.

samatman 6y ago
I'm not 100% confident I follow, but this sounds like one of those backflips Rust programmers do to satisfy the borrow checker. As in, you wouldn't write the code this way if you didn't have to. You do get memory safety in return... but you can see where the desire for a more eloquent approach might arise.
- gautamcgoel 6y ago
  For a moment I thought Sam Altman was spending his time reading random HN forums and commenting on the intricacies of Rust coding. Took me a minute to catch the missing "l" in your handle ;)
  - samatman 6y ago
    haha I'm not sama and have been using this handle, and variants, for longer than he's been alive. But you're not the first to think so!
klodolph 6y ago
> What about making the object borrow from the closure? That doesn't actually guarantee that the closure will outlive the object. You would need linear types in order to do that, and Rust does not have linear types. In the particular API I'm working with, you pass the closure in to an object when you create it, and you have to make sure that the closure outlives the object. The only way to do that within the Rust type system is by making the closure 'static, which is... less than ideal. So you use unsafe{} instead. This is because any object may outlive its specified lifetime. Lifetimes are only lower bounds. So if I have lifetimes 'b and 'a, and 'b : 'a, this only means that the LIFETIME 'b must be at least as long as the LIFETIME 'a, but any particular object with lifetime 'b may live arbitrarily long, as long as it lasts at least as long as 'b. And any object which is 'a may last arbitrarily long, but at least as long as 'a.

samatman 6y ago

I'm not 100% confident I follow, but this sounds like one of those backflips Rust programmers do to satisfy the borrow checker. As in, you wouldn't write the code this way if you didn't have to. You do get memory safety in return... but you can see where the desire for a more eloquent approach might arise.

gautamcgoel 6y ago
For a moment I thought Sam Altman was spending his time reading random HN forums and commenting on the intricacies of Rust coding. Took me a minute to catch the missing "l" in your handle ;)
- samatman 6y ago
  haha I'm not sama and have been using this handle, and variants, for longer than he's been alive. But you're not the first to think so!

klodolph 6y ago

> What about making the object borrow from the closure? That doesn't actually guarantee that the closure will outlive the object. You would need linear types in order to do that, and Rust does not have linear types. In the particular API I'm working with, you pass the closure in to an object when you create it, and you have to make sure that the closure outlives the object. The only way to do that within the Rust type system is by making the closure 'static, which is... less than ideal. So you use unsafe{} instead. This is because any object may outlive its specified lifetime. Lifetimes are only lower bounds. So if I have lifetimes 'b and 'a, and 'b : 'a, this only means that the LIFETIME 'b must be at least as long as the LIFETIME 'a, but any particular object with lifetime 'b may live arbitrarily long, as long as it lasts at least as long as 'b. And any object which is 'a may last arbitrarily long, but at least as long as 'a.