vec! macro should use box [...] instead of Box::new([...]).

[eddyb]

There's no reason to have the potentially unoptimizable inefficiency in vec!.
It's impossible to reoder side-effects (which is why we want placement syntax), so vec![expressions, containing, side, effects] will end up in a copy from the stack to the heap.

I guess it's not as bad as I thought given that vec![x; N] goes through a more optimal route so you can't cause a stack overflow with it.

[apasel422]

Wouldn't this require #![feature(box_syntax)] in all crates that use the macro?

[eddyb]

Not at all, formatting and TLS macros already use unstable features in their implementation.
There was some work put into making this possible, we might as well make use of it.

[apasel422]

Ah, I see. I'm looking into implementing this.