Hacker News Reader

Comment by Ericson2314 | Hacker News Reader

We need &out and &in, so we can safely write this stuff by hand. Then we can worry about the compiler automatically optimizing to use &out behind the scenes (using ABI flexibility).

Trying to skip that first step, so the compiler just does unverified shit behind the scenes, I think will just end up with inflexibility and disappointment. Be the tortoise not the hare.

View on HN

Easier said than done. You can already have:

    unsafe fn new_in_place(out: &mut MaybeUninit<MyType>)

But you require unsafe code both to implement it (to project MaybeUninit) and to call it.

For it to be safe to call the type system would have to encode the invariant that &out is initialised after the call. It becomes even more complicated if the operation can fail.

Yes, you do. This is the cost of doing business. I'm OK with it.

If one doesn't want to deal with imperative programming in all its glory, go write Haskell or something. (I do that too.)

As a stepping stone. we could worry just about the panic=abort case, where this is all easier.

For panicking, I think we would want to switch to a model where borrower not borowee runs destructor for &mut; that way we can support "moving out of &mut temporarily" too.

Reply on news.ycombinator.com