You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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::newis inline always, or does that not work?
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::newis implemented in terms of it) and in the wider ecosystem (unlike<-etc which only had a handful of crates using it).Things to decide:
boxsyntax be phased out?Box::newis inline always, or does that not work?boxandinexpressions (tracking issue for RFC 809) #22181 about the syntax behaviourNote: when removing this, be careful not to remove the syntax entirely in order to not cause another case of #50832