https://issues.dlang.org/show_bug.cgi?id=12918
--- Comment #2 from Jonathan M Davis <[email protected]> --- > Implicit functionality cause problems, so you need something significant to > justify its presence. What are some use cases of code like that? It's inconsistent that it doesn't work. Copying on the stack works just fine already, why shouldn't it just work for you to be able to construct an object on the heap which is a copy of one on the stack? And this code works right now void main() { int i = 5; auto j = new int(i); } It just doesn't work with structs for some reason. As it stands, you're forced to either do something like auto g = new Foo; *g = f; which is overly verbose and doesn't work with const or immutable, or you're forced to create an extra constructor that basically does what a postblit already does except that it's for the heap. So, this affects all code that wants to create a copy of a struct on the heap. Also, I don't see how the requested behavior could cause any problems. The only code which would be affected is code that already defines a constructor which takes a variable of the same type, and that could continue to work as it does now. Code that doesn't do that could then start taking advantage of the new behavior it wanted to, but all this is doing is the exact same thing that a postlblit constructor does except on the heap, and postblit constructors are already implicitly defined if you don't defined them. And I would fully expect that this feature would use the postblit constructor. It's just that it would then be copying to the heap rather than the stack. --
