Aside – some ramblings about `&move` references

So I finally gathered my thoughts about this topic. First, a couple of questions:

  • Your implementation called RefOwn above doesn't really need to be a language feature, does it?
  • (As an aside, shouldn't there be a mechanism for setting the MaybeUninit back to an uninitialized state in RefOwn::drop?)

Furthermore, there's one particular thing I would like to address:

I agree that this kind of magic would be detrimental to the design and usability of the language. However, I think there's a fundamental issue that is inherent to the problem and is not easily solvable. An owning pointer without heap-allocation will always have to have some sort of stable-address storage of an appropriate lifetime. I think trying to hide this behind a Box-like API and expecting it to "just work" is not reasonable.

In addition, ownership of unsized values, if ever solved, should be done in the same fashion for function arguments as it is implemented in the rest of the language; I see no good reason why function arguments should get special treatment. Of course, plain unsized_locals would cause memcpying, but I'm still not convinced (at least I can't find an argument in your post) that this is such a big deal.

It might be a big deal in special cases, but then couldn't one get away with either your library or by manually implementing a similar MaybeUninit-based abstraction? Introducing a whole new fundamental reference type into the language just for the sake of solving very special performance problems which potentially stem from the optimizer not being smart enough doesn't seem like the right tradeoff for me.

1 Like