[lang-team-minutes] feature status report: placement in and box

[rkruppe]

A12 is about desugaring PLACE <- EXPR (or whatever the syntax would be) to something like PLACE.emplace(|| EXPR). Such a desugaring would silently change the meaning of EXPR w.r.t. control flow. It’s true that people could write out the closure form themselves and then they’d have no one to blame but themselves if they tried to return (of break, or …) from the closure.

So, I misspoke when I said new syntax is strictly necessary. If we require people to write out closures manually, that could generate the desired code. For that matter, we could also have a macro that does the current desugaring (as long as we decided that we don’t want auto-ref). One of the placement RFCs in fact gave an example implementation in the form of a macro.

So I am again reduced to an appeal to ergonomics: Placement is strictly more efficient than other forms of construction, so it should be more convenient than those other methods, to ensure it is used over them.

[troplin]

I suppose what I’m asking is whether we’ve considered some equivalent mechanism to how C++ forwards arguments (I’m not 100% on how this pans out in C++, so this is just wishful thinking on my part).

AFAIK, C++ uses:

1. Variadic template methods that basically accept any possible combination of arguments.

• Perfect forwarding (RValue-References + Reference collapsing + std::forward) to forward the arguments to constructor
• The fact that constructors are already a special case, not just static methods that return a value.

I think especially point 1 is problematic. It means unrestricted overloading with variable arguments and without any constraints (traits), which is very far from how generics work in Rust.

[cuviper]

The fact that constructors are already a special case, not just static methods that return a value.

Yes, especially that this in a C++ constructor is a pointer to as-yet-uninitialized memory.

I think a fairly direct parallel in Rust would be something like:

struct Vec<T> {
    fn emplace_back<C>(&mut self, ctor: C)
        where C: FnOnce(*mut T)
    {
        let this: *mut T = self.reserve_uninitialized_slot();
        ctor(this);
        // ... plus some panic handling
    }
}

The closure’s environment can take the place of arbitrary variadic templates, but making the initialization happen in place is the tricky part to me.

[gnzlbg]

Whatever solution is chosen must make the following program always correct (playground):

const N: usize = 512;  // works in my platform for 256 but not 512 =/
type FixedSizeMatrix = [[f64; N]; N];
let u : Box<FixedSizeMatrix> = Box::new([[0.; N]; N]); 

The current issue is that inside Box::new(EXPR), result of EXPR is allocated on the stack, and then passed to new, which moves it to the heap. It works in release because the optimizer removes the unnecessary stack allocations.

IIUC placement in is a language construct (analogous to placement new) to force the result of EXPR to be allocated at a concrete memory location, which solves this problem (and others). I do not want to run into, what Bjarne describes as: “Something must be done. This is something. Therefore we must do this”.

The original placement box RFC says:

This provides a way for a user to specify (1.) how the backing storage for some datum should be allocated, (2.) that the allocation should be ordered before the evaluation of the datum, and (3.) that the datum should preferably be stored directly into the backing storage (rather than allocating temporary storage on the stack and then copying the datum from the stack into the backing storage)

After re-reading the RFC, I see that there are many use-cases being discussed. But if I focus on the simplest example shown above, I don’t feel that the following question has been answered with sufficient clarity in the RFC and associated discussions:

Why cannot the example above be made to work correctly and reliably without extra syntax?

That is, without focusing on other usages / applications of a possible placement in language feature, could the language require that when the result of an expression is directly consumed by another expression, the expression must be inlined when possible (for some definition of possible) and the temporary storage guaranteed to be eliminated?

[notriddle]

Not in the presence of panicking and other divergent expressions. We want the heap storage to be allocated before the expression is evaluated. If the expression panics, the heap storage needs to be freed without executing the destructor. Maybe it can be done without custom syntax, but it can’t be done without a placer interface that the containers have to implement.

[Storyyeller]

I think there’s two seperate issues - what the syntax looks like for the user and what the syntax looks like for the library.

Since user code is more common, obviously we should optimize for that case. In particular, it would be great if you could just write Box::new(expr) or Rc::new(expr) or vec.push(expr) and have the compiler do the right thing.

As far as I can tell, the only reason this optimization can’t be done completely automatically is order of evaluation issues in the case of placement (note that there is no such concern for placeless allocation like Box::new and Rc::new).

In the case of Vec::push, doing the allocation changes the state of the vec, and there’s interesting questions surrounding what will happen if EXPR involves borrowing vec, as well as if it panics or completes abruptly. This sounds similar to the Non Lexical Lifetime issue, so maybe we should wait to see how they decide to handle stuff like vec.push(vec.capacity()) first.

[vadimcn]

A12 is about desugaring PLACE <- EXPR (or whatever the syntax would be) to something like PLACE.emplace(|| EXPR).

Sure, but I’ve seen similar arguments used against direct usage of closures for emplacement.

It’s true that people could write out the closure form themselves and then they’d have no one to blame but themselves if they tried to return (of break, or …) from the closure.

This sounds like an advantage of the closure form, really: vec.place_back(|| run_code()?) will give you a type error, whereas vec <- run_code()? will compile, but won’t do the intended optimization.

So I am again reduced to an appeal to ergonomics: Placement is strictly more efficient than other forms of construction, so it should be more convenient than those other methods, to ensure it is used over them.

vec.place_back() <- x is not even shorter than vec.place_back(|| x)

To win on the number of characters typed, we’d need to figure out auto-ref’ing, so one could write vec <- x. Which opens a wholly new can of worms, it seems.

[rkruppe]

To win on the number of characters typed, we’d need to figure out auto-ref’ing, so one could write vec <- x. Which opens a wholly new can of worms, it seems.

Without auto-ref we could still have &mut vec <- x, or plain vec <- x if vec is actually a &mut Vec (not at all rare). But yes, auto-ref is a big win. I don’t see what can of worms it opens, other than the current implementation (HIR expansion) being unsuitable — but at least for box, the implementation may already change for other reasons (type inference) as outlined in the OP.

And it’s not just, and not primarily, about the number of characters typed. In my and other people’s vision, <- would be the default, the most simple and aesthetic way of inserting in a collection: the <- syntax is visually evocative, it’s the same for different collections (Vec::push vs. HashSet::insert), and it has less visual noise than the alternatives (no parentheses, no || prefix).

This sounds like an advantage of the closure form, really: vec.place_back(|| run_code()?) will give you a type error, whereas vec <- run_code()? will compile, but won’t do the intended optimization.

While reading this, it occurred to me that the closure form actually isn’t equivalent in the number of moves! In the following example (after whatever temporaries and moves are involved in try! or ?), the payload of the Ok variant is moved into the local arg, then moved into the closure object, and then finally moved into the Vec's backing buffer.

let arg = try!(compute_argument());
vec.emplace(|| arg);

Contrast this with the <- equivalent (vec <- try!(arg);), which does indeed need a temporary for the Result just like the above code, but in the Ok case directly (again, after whatever happens in the try!) copies the payload into the Vec's memory. And despite the closure being quite inlinable, the move from the Result temporary into the local occurs before the memory allocation, so we can’t be sure it gets reordered. (Not to mention that the closure isn’t 100% guaranteed to be inlined, the fact that LLVM has been and still is less-than-stellar about optimizing memcpys, and a million other minor wrinkles.)

So there’s that. But even if it were fully equivalent, I don’t think we’d want the error that the closure implies. That would assume people only use placement (in whatever form) when they absolutely positively need the optimization and can not tolerate anything less. This is antithetical to the vision of placement becoming the default syntax — it doesn’t always have to be always faster (the ? case needs a temporary regardless of how you approach it), it just has to be always at least as fast as the alternatives (Vec::push and your hypothetical Vec::emplace).

Besides, Rust makes a point of being relatively explicit about costs, if you know what to look for, but it doesn’t go out of its way to actively penalize slight inefficencies. If someone does not know, or does not care, that a ? expression involves an extra temporary, forcing them to move the ? out of the closure doesn’t help them, it just force them to write uglier code and prolong the “fight the compiler” phase. Furthermore, even if we wanted to highlight these situations, a lint could do the job just as well, but one could silence it.

[canndrew]

I just want to mention again that i don’t think it makes any sense to settle on a design for this until we’ve figured out a design for &in / &place pointers (ie. the opposite of &move pointers).

[eddyb]

Neither &move nor “out-pointers” are really ergonomic without being parametrized on the allocation and owning it.

IOW, the Place types in the RFC are one of the few realistic versions of out-pointers for Rust (you could also imagine having a single type with a generic parameter, but the two are mostly equivalent), there just is no Place type provided for stack slots, only everything else. That makes p <- x what would otherwise be *p = x.

[Storyyeller]

Without auto-ref we could still have &mut vec <- x, or plain vec <- x if vec is actually a &mut Vec (not at all rare). But yes, auto-ref is a big win. I don’t see what can of worms it opens, other than the current implementation (HIR expansion) being unsuitable — but at least for box, the implementation may already change for other reasons (type inference) as outlined in the OP.

And it’s not just, and not primarily, about the number of characters typed. In my and other people’s vision, <- would be the default, the most simple and aesthetic way of inserting in a collection: the <- syntax is visually evocative, it’s the same for different collections (Vec::push vs. HashSet::insert), and it has less visual noise than the alternatives (no parentheses, no || prefix).

I really don’t like vec <- x because it seems confusing and ambiguous to me. For example, with a vec, you usually want to push to the back, but for a deque, you can efficiently append to either end. And it’s not like you can’t insert into the beginning of a vec either, it’s just slower than inserting to the back. So it’s not immediately clear what vec <-x even means.

Apart from that, Go uses <- for an unrelated operation (sending and receiving on a channel), so that would increase confusion as well.

[devyn]

Apart from that, Go uses <- for an unrelated operation (sending and receiving on a channel), so that would increase confusion as well.

Placement could be conceivably implemented for channels as well, since they’re basically collections purpose-built for communication and synchronization. It makes enough sense to me that one could do

tx <- MyMessage(42)

instead of

tx.send(MyMessage(42))

with all of the benefits of in-place allocation that this could potentially get you.

[oln]

Are there any updates on this? Is box syntax dependent on the rest of the functionality here, or would it be possible to stabilise box as it works in nightly before having the rest of the details sorted?

[pnkfelix]

One problem with stabilizing box as it works in nightly: It might prematurely stabilize a strong connection between box <expr> and Box<T> (for an expr: T), which in turn might make it difficult to generalize box in the future to other container types in a backward-compatible fashion.

Basically, we’ve been holding off stabilizing box until we make more progress on generalizing box (or, alternatively, deciding that generalizing box is not worth the effort/cost…)

[oln]

Would it be an idea to special case Box::new(x) to simply act the same as the current unstable box x while this is not stabilised? That’s what the Box::new function contains anyhow, but it doesn’t seem to always inline properly. I don’t think there are any ways of guaranteeing heap allocations without temporaries on stable at the moment without delving into unsafe, especially on lower optimisation levels.

[withoutboats]

How would that special case work?

[gulbanana]

Perhaps by using call-by-name semantics.

[bjorn3]

#[inline(always)]?

[oln]

Consider MIR output (current rustc doesn’t really do any optimisation on the mir level at the moment except cleaning up &*, so debug and nightly is similar) of this code: https://is.gd/WvMCrx

My suggestion is that the compiler could emit MIR similar to the one emitted by box x when it encounters Box::new(x) rather than emitting the normal function call mir (ie. treat it as if it encountered box x. This lets LLVM optimise the function much better, if you look at the assembly output of the same functions. If you look at the MIR for the Box::new version it creates a temporary array on the stack (an possibly another one inside the function call). I don’t know the compiler internals well enough to say the exact details of how this could be implemented.

Another temporary alternative could maybe be a boxed! macro similar to vec!.

[pnkfelix]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.