Pre-RFC: placement box with Placer trait

internals ideas (deprecated)
6

Actually, re-reading Gankro’s comment and the RFC, I got to thinking about the mutability of varous things here.

  1. I suspect that the pointer method on PlacementAgent ought to take &mut self.
  2. I don’t see why it matters or should be expected for "pointer" to be cheap in particular. We expect to call it once, after all.
  3. The use of &self on the Placer trait isn’t ideal. Perhaps removing the Placer trait and having just the PlacementAgent would be the right thing after all.

It would be nice if you could write all of the following:

  1. box(in RC) foo
  2. box(in vec.emplace_back()) foo
  3. box(in arena) foo

(I’m not sure yet which syntax I prefer, I thought i’d experiment)

But I’m not sure we can have all three. But maybe that’s just fine.

The first one seems to work most anyway we do it. RC is a global constant, so it is actually an rvalue at the moment, but even if we eventually allowed global constants to be lvalues, then it could implement Copy as it has no state, and hence it could potentially serve as the placement agent (though the expansion would have to carry the data type T externally).

The second one really prefers no placer at all.

The third one wants the current design.

Finally, looking forward to when we have customizable memory allocators, we probably want a fourth use case, which is the ability to put a box in a specific allocator. The protocol can accommodate this fine, but it’s another instance where, similar to emplace_back, you don’t really need the Placer trait. I imagine it would look something like:

box(in Rc(alloc)) foo

Anyway, I’ll try to sketch out what I mean in more detail, but atm I am leaning towards saying we can remove the Placer trait after all (I know I poopoo’d the idea last time you raised it, sorry).