Tracking issue for box_syntax

[aidanhs]

This is a tracking issue for the box_syntax feature, the special syntax for creating boxes, e.g. box 1usize (note: box patterns is separate and is tracked at at #29641)

This was previously under the same tracking issues as placement (#22181/#27779) but I didn't want to remove it (yet) due to widespread usage in the compiler (Box::new is implemented in terms of it) and in the wider ecosystem (unlike <- etc which only had a handful of crates using it).

Things to decide:

• how should box syntax be phased out?
  • how easy is it to remove box syntax as a language feature? Can we just describe it as "will never be stabilised in its current form as it's an internal implementation detail, may be stabilised under a new design of placement")?
    • if it were possible to remove it as a language feature, is it reasonable to do so without a replacement in the form of working placement?
    • if we want to keep box syntax internally, should we rename (but keep reserved) the keyword to something else to deliberately break users and indicate it shouldn't be used for placement?
  • is there any reason for users to use box syntax (apart from it looking nice) given Box::new is inline always, or does that not work?
• if we decide to keep this, there are a number of unresolved questions in #22181 about the syntax behaviour

Note: when removing this, be careful not to remove the syntax entirely in order to not cause another case of #50832

[spacekookie]

Do I understand it correctly that the box syntax is dependent on placement-new (which has now been unapproved as an RFC)?

Personally I like the idea of having some syntactic sugar for creating something as common as a box (it does look nice). But obviously it would need to be built on something that works.

[steveklabnik]

@spacekookie yes, the big deal for box syntax is placement new.

[oyvindln]

s there any reason for users to use box syntax (apart from it looking nice) given Box::new is inline always, or does that not work?

It doesn't optimize well, and even if it did, you would need some other way around it to avoid blowing up the stack in debug mode.
#41160

[mark-i-m]

is there any reason for users to use box syntax (apart from it looking nice) given Box::new is inline always, or does that not work?

So this is perhaps a bit of a weird usecase, but it is the only reason I have used box at all: I do a lot of no_std projects where the stack doesn't grow automatically. In these cases, using Box::new(MyLargeStruct) will overrun the limited amount of stack space by allocating MyLargeStruct on the stack and copying it to the allocated space. Allocating and initializing in place is critical.

The obvious alternative is to use the allocator directly and unsafely construct a Box from it, but that's annoying and ugly.

See example here: https://github.com/mark-i-m/os2/blob/2ab9d589a4463bd3133157b5c1a2f9f6735a3432/kernel/process/sched.rs#L76-L83

[ice1000]

In most cases people just want to simplify the Box::news everywhere. I really want a shorter version and box syntax sounds like a great idea.
Is there a recent plan of stabilizing box syntax?