box syntax

[ftxqxd]

The current box syntax (box(PLACE) EXPR) has a few flaws in my opinion:

• it makes it difficult to parenthesise the expression if the place is omitted, which is quite a commonly-encountered scenario;
• it resembles a function call, although it’s not really a function.

This syntax never went through a proper RFC, so it didn’t get much feedback. Here are some ideas I’ve come up with or have maybe seen about the place; I don’t really like any of them much, but they mostly fix my issues with the current syntax:

• box(in PLACE) EXPR: resolves parsing issues, but looks a bit weird;
• box EXPR in PLACE: resolves parsing issues and looks less like a function call, but moves the place to the end, which is not usually desirable as the expression is usually longer;
• box::(PLACE) EXPR: resolves parsing issues and looks very weird, but less like a function call. Steals syntax from disambiguating generic method calls;
• box(PLACE) EXPR (the current syntax), but after parsing the ) after the place, check that the next token can start an expression (the strategy adopted by Parse bracketed box expressions rust#16863). Still has a bit of ambiguity in if/while/for expressions (e.g., if foo == box (bar) { ... }), but otherwise resolves most parsing issues. Has the advantage of simplicity.

If the current syntax stays, we should at least omit a helpful message whenever the expression is missing from a box expression. I plan on implementing this shortly.

[thestinger]

It's important for PLACE to allow operations like collection inserts too.

[blaenk]

I like box EXPR in PLACE but your point about the expression typically being longer is a good one, so I propose we flip it and do in PLACE box EXPR, this allows us to continue to do box EXPR easily and only prefix in PLACE if we need it, allowing the expression to be as long as it needs to be.

[pnkfelix]

(The other (IMO more important) reason why PLACE should appear somewhere to the left of EXPR is that it properly reflects the evaluation order, which is indeed the whole point of having this syntax in the first place. edit: okay, maybe not "whole point", but its significant...)

[reem]

It's never been clearly documented anywhere what the idea behind and plans for this syntax are, and that will inform this discussion significantly. For instance, I was surprised to see @thestinger say that this syntax should support collection inserts, I thought it was mostly for allocations i.e. box(Gc) x, box(Rc) x, box(Arc) y, etc.

[thestinger]

It's meant to cover the same use cases as placement new and perfect forwarding in C++. Those allow in-place construction of elements in smart pointers, collections and more.

[dobkeratops]

How about,
box expr
box.Gc expr
box.Rc expr

expresses its refinement of the 'box', like box(?) does, but more syntactically compact and unambiguous due to location of box vs .

I think that would be very clear to read, but I realise it has no precedent in the syntax, it might be hard to guess. Then again its not like box(Gc) was a function call either.

[huonw]

@dobkeratops how does that work with in-place construction in containers, or even just a custom allocator with Box? (e.g. box(vec.emplace_back()) foo() would write foo() directly into the memory at the end of vec.)

[dobkeratops]

box.vec.emplace_back() foo() ... ok thats a bit messy, but it does still get rid of the ambiguity

I haven't seen the proposes for emplace back... would it make sense for it to read a bit like 'method of the container' - and reverse it e.g.

vec.emplace_back().box foo()
Gc.box foo()
myvec.box foo()

not sure which makes more sense or is least confusing.

[nikomatsakis]

See http://discuss.rust-lang.org/t/pre-rfc-placement-box-with-placer-trait/729

[steveklabnik]

with #809 merged, I'm going to give this a close. If any of the concerns in this thread weren't addressed, let's open new issues specific to that (though I think they were)