[Issue 12918] Copying-constructing structs onto the heap

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12918

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4

--

[Issue 12918] Copying-constructing structs onto the heap

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12918

Thayne  changed:

   What|Removed |Added

 CC||astrotha...@gmail.com

--- Comment #4 from Thayne  ---
A workaround for this is to allocate a Foo then assign it to the struct.

struct Foo
{
int i;
}

void main()
{
auto f = Foo(5);
auto g = new Foo;
*g = f;
}

However, if the Foo struct has the default constructor disabled (@disable
this();) then this doesn't work, even if postblit isn't disabled. The only way
I can think of to get this to work in general would be something like this:

auto f= Foo(5);
auto g = cast(Foo*) (new ubyte[Foo.sizeof]).ptr;
*g = f;

which is pretty awkward.

--

[Issue 12918] Copying-constructing structs onto the heap

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12918

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|unspecified |D2

--

[Issue 12918] Copying-constructing structs onto the heap

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12918

Matt Kline mkline.o...@gmail.com changed:

   What|Removed |Added

 CC||mkline.o...@gmail.com

--- Comment #3 from Matt Kline mkline.o...@gmail.com ---
(In reply to bearophile_hugs from comment #1)

 What are some use cases of code like that?

Say struct Foo has a member Bar* b, which can either contain some optional data
or be null to indicate that no such data is currently present.

From some other data structure, you procure an instance of Bar (call it other)
which you would like to assign to b. However, to make the lifetime of b
independent of its source, you want to create a garbage-collected copy of other
and assign it to b.

--

[Issue 12918] Copying-constructing structs onto the heap

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12918

Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

Summary|Copying structs on the heap |Copying-constructing
   ||structs onto the heap

--

[Issue 12918] Copying-constructing structs onto the heap

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12918

bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc

--- Comment #1 from bearophile_h...@eml.cc ---
(In reply to Jonathan M Davis from comment #0)

 I think that this code should compile
 
 struct Foo
 {
 int i;
 }
 
 void main()
 {
 auto f = Foo(5);
 auto g = new Foo(f);
 }

Implicit functionality cause problems, so you need something significant to
justify its presence. What are some use cases of code like that?

--

[Issue 12918] Copying-constructing structs onto the heap

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12918

--- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com ---
 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.

--