Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem here is that performing the optimization can change the semantics of the program, if you consider order of memory allocation to be part of the semantics. If the object you're creating itself has memory allocations within it, then allocating the box before constructing contents will change the order of the mallocs. C++ compilers will not do this optimization for this reason, though C++ has emplace so that the programmer can manually work around it. For this reason I think that it may be best to just introduce an emplace-like pattern for Rust as well.

If constructing the object doesn't have side effects, however, then we should be able to hoist the allocation at the optimizer level.



> if you consider order of memory allocation to be part of the semantics

Don't do that, then? :)

LLVM can already do heap-to-stack, so people don't seem to feel too strongly that exactly preserving heap allocations is worth it. And what does that mean on multi-core, anyway?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: