Executive summary: We are not ready to stabilize the placement in and box forms yet. We would like the forms to have a better user experience before stabilization.
Bullet point summary:
box EXPRis not implemented yet
- Consider desugaring from HIR to MIR (rather than source to source) to address inference issues with
box EXPRtoo easily confused with
Box<T>? Should we change the syntax?
- Probably need to add autoref to
vec <- 22,
vec.back() <- 22, and
arena <- 22
- Consider reworking
Placerin light of generic associated types (aka “Associated Type Constructors”).
- Allocator integration?
Status Report: Placement In and Box
During the language team meeting on January 19th, the team discussed the
box EXPR and placement in
PLACER <- EXPR syntactic forms.
(To see the original goals for these forms, see RFC 809.)
In particular, the key question we wanted to answer was: Where are these forms on their respective paths towards stabilization? Are we happy with their current semantics and should stabilize them as is, or do they need further revision before stabilization? (Or perhaps are they not pulling their weight and should be deprecated?)
Current implementation status: Support for
<- and the traits for overloading the operators has landed. But
box EXPR is not yet overloaded; it is tied solely to
The reason that
box EXPR was not yet overloaded is that the desugaring-based implementation that works for
<- does not generalize nicely;
box EXPR, due to type-inference issues (the inference ends up trying to assign unsized types to stack locals in the desugaring).
- We may want to switch from a source-to-source desugaring to a HIR->MIR desugaring. This may help address the type inference issues.
While discussing overloading
box EXPR, a common concern was that this form is simply too confusing, because
box sounds like
Box, and so the current non-overloaded semantics is in fact the one that everyone expects.
- An alternative might be to syntactically-overload
- e.g. things like
let x: Rc<_> <- EXPRbeing the new way to say
let x: Rc<_> = box EXPR
Placement In Syntax and Protocol
PLACER <- EXPR is implemented, it is agreed that the current semantics is not ready for stabilization. In particular, the placement protocol is designed to always consume the
PLACER. This consumption semantics works for some placers (like
&Arena since it is Copy), but it is likely to rule out desirable uses.
See RFC Issue 1286 for further discussion of the protocol’s consumption of the placer.
The discussion at RFC Issue 1286 focused largely on changing the trait definitions rather than the desugaring. However, the discussion did expand to include options like doing auto-ref on the PLACER in
PLACER <- EXPR. This way we could support
vec <- 22;and
vec.back() <- 22;and
arena <- 22;which require
Related to the placer-consumption question, the lang team discussed whether or not making
vec <- 55; “work” (as a way to push that integer onto the end of the vector) is desirable.
- Currently one must instead write
vec.place_back() <- 55;,
place_backseems pretty onerous, in terms of convincing new-comers that this matches “best practices”,
- (Obviously supporting
vec <- 55;requires the change that the placement protocol not consume the
PLACER; but that implication is only one-directional.)
Finally, it is possible that future language features like generic associated types may yield much better designs for the Placer trait.
Some people have asked about how placement in will integrate with allocators. Landing allocators stalled somewhat, but now that
#[may_dangle] support has landed, @pnkfelix plans to put up a PR for allocator-support in libcollections soon.
It remains to be seen how well the placement syntax and protocol will mesh with allocators (RFC 1398.)
Time Line for Work
It is not clear if we will put effort into placement-in or box in 2017, since it is not really on the roadmap (except perhaps if one regards the syntax
v <- 55 as a big boon for usability).