Closed
Description
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?
- 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 we decide to keep this, there are a number of unresolved questions in
box
andin
expressions (tracking issue for RFC 809)Β #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