www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bypassing the postblit?

reply "Ritu" <ritu metaprogramming.net> writes:
Dear D Experts

I have a situation where I want to pass a D struct object as an 
argument to a function. Now in my case, I do not want to invoke 
the default D copy constructor for the struct. Is there a way of 
doing that? I have tried disabling the postblit and enabling 
another constructor via "alias this" (see the code below). But 
the compiler does not like that, and I get an error that tells me 
that the Bar is not copyable since it has been disabled:

struct Bar {
    disable this(this);
   alias _foo this;
   Foo _foo;
   public this(Foo foo) {
     this._foo = foo;
   }
}

class Foo {}

void main() {
   Bar bar;
   Bar baz = bar;
}

Regards
Ritu
Dec 25 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 26 December 2013 at 05:06:26 UTC, Ritu wrote:

 Dear D Experts

 I have a situation where I want to pass a D struct object as an 
 argument to a function. Now in my case, I do not want to invoke 
 the default D copy constructor for the struct. Is there a way 
 of doing that? I have tried disabling the postblit and enabling 
 another constructor via "alias this" (see the code below). But 
 the compiler does not like that, and I get an error that tells 
 me that the Bar is not copyable since it has been disabled:

 struct Bar {
    disable this(this);
   alias _foo this;
   Foo _foo;
   public this(Foo foo) {
     this._foo = foo;
   }
 }

 class Foo {}

 void main() {
   Bar bar;
   Bar baz = bar;
 }

 Regards
 Ritu


D struct copying is done by a bit-level copy of the source. A 
postblit - the closest we have to a struct copy constructor - is 
only run if you specify one yourself, i.e. there is no default 
one to disable.
Dec 26 2013
parent reply "Ritu" <ritu metaprogramming.net> writes:
 D struct copying is done by a bit-level copy of the source. A 
 postblit - the closest we have to a struct copy constructor - 
 is only run if you specify one yourself, i.e. there is no 
 default one to disable.


Thanks John

Ok. Let me rephrase the question. I do not want to perform 
bit-wise copy of my struct, but I want to specify my own copy 
semantics. Is there a way?

Regards
Ritu
Dec 26 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 12/26/2013 05:43 PM, Ritu wrote:


 D struct copying is done by a bit-level copy of the source. A postblit
 - the closest we have to a struct copy constructor - is only run if
 you specify one yourself, i.e. there is no default one to disable.


 Thanks John

 Ok. Let me rephrase the question. I do not want to perform bit-wise copy
 of my struct, but I want to specify my own copy semantics. Is there a 


way?

No. In D, struct are freely copied or moved depending on whether the 
source is an lvalue or an rvalue. What is possible is to define the 
post-blit function to work on the already-blitted destination object.

For example, if you don't want the source and the destination share a 
member slice, the destination object's post-blit can make a copy.


 Regards
 Ritu


Ali

P.S. There is also the D.learn newsgroup where such threads are enjoyed 
even more. :)
Dec 26 2013
parent reply "Ritu" <ritu metaprogramming.net> writes:
 No. In D, struct are freely copied or moved depending on 
 whether the source is an lvalue or an rvalue. What is possible 
 is to define the post-blit function to work on the 
 already-blitted destination object.

 For example, if you don't want the source and the destination 
 share a member slice, the destination object's post-blit can 
 make a copy.


Ok, I will give you some background of what I am trying to do.

I have a struct that wraps a class object and lazily initializes 
it. Now in case the struct instance is passed as an argument to a 
function and it has not been initialized yet, the default copy 
constructor and the postblit do not offer a possibility to 
initialize the class object before copying.

Any possibility of *preblit* kind functionality?

Regards
- Ritu
Dec 29 2013
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 29.12.2013 17:22, schrieb Ritu:

 No. In D, struct are freely copied or moved depending on whether the
 source is an lvalue or an rvalue. What is possible is to define the
 post-blit function to work on the already-blitted destination object.

 For example, if you don't want the source and the destination share a
 member slice, the destination object's post-blit can make a copy.


 Ok, I will give you some background of what I am trying to do.

 I have a struct that wraps a class object and lazily initializes it. Now
 in case the struct instance is passed as an argument to a function and
 it has not been initialized yet, the default copy constructor and the
 postblit do not offer a possibility to initialize the class object
 before copying.

 Any possibility of *preblit* kind functionality?

 Regards
 - Ritu


No unfortunately not. You could solve the issue by adding another level 
of indirection. So always allocate the additional indirection, then its 
save to copy it, and then you can lazy instaniate the actual instance 
when needed and all copies of your wrapper will see the instance.

Kind Regards
Benjamin Thaut
Dec 29 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 29 December 2013 at 18:27:16 UTC, Benjamin Thaut wrote:

 No unfortunately not. You could solve the issue by adding 
 another level of indirection. So always allocate the additional 
 indirection, then its save to copy it, and then you can lazy 
 instaniate the actual instance when needed and all copies of 
 your wrapper will see the instance.

 Kind Regards
 Benjamin Thaut


Even with that, you'd still have to make sure the newly inserted 
indirection gets initialized *prior* to the copy, so it's back to 
square one...


 Am 29.12.2013 17:22, schrieb Ritu:

 Ok, I will give you some background of what I am trying to do.

 I have a struct that wraps a class object and lazily 
 initializes it. Now
 in case the struct instance is passed as an argument to a 
 function and
 it has not been initialized yet, the default copy constructor 
 and the
 postblit do not offer a possibility to initialize the class 
 object
 before copying.

 Any possibility of *preblit* kind functionality?

 Regards
 - Ritu




Nope. What you are asking for is basically a default constructor, 
which D does not provide. Workarounds include the "static opCall" 
pattern, as well as the "function builder" pattern (eg: "MyStruct 
myStruct(Args args)")
Dec 29 2013
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 29.12.2013 20:26, schrieb monarch_dodra:

 Even with that, you'd still have to make sure the newly inserted
 indirection gets initialized *prior* to the copy, so it's back to square
 one...


For that you can easily disable the default constructor. And then make 
the user call a constructor of your choosing that way. I thought the 
entire point of this preblit was that both the original and the copy 
point to the same instance, when the instance is actually requested.

Kind Regards
Benjamin Thaut
Dec 29 2013
prev sibling next sibling parent reply "Ritu" <ritu metaprogramming.net> writes:
 Nope. What you are asking for is basically a default 
 constructor, which D does not provide.


Ok. Now I get why preblit can not be there.

Now how about postblit making both the source and target struct 
instance available? D makes only target object available. Is 
there a limitation why both source and target can not be made 
available?

Regards
- Ritu
Dec 30 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 30 December 2013 at 08:15:21 UTC, Ritu wrote:

 Nope. What you are asking for is basically a default 
 constructor, which D does not provide.


 Ok. Now I get why preblit can not be there.

 Now how about postblit making both the source and target struct 
 instance available? D makes only target object available. Is 
 there a limitation why both source and target can not be made 
 available?

 Regards
 - Ritu


Why would you want access to the original struct though, if you 
have a bit for bit copy? The *only* reason I could imagine, is to 
*mutate* the original struct...
Dec 30 2013
parent reply "Ritu" <ritu metaprogramming.net> writes:
 Why would you want access to the original struct though, if you 
 have a bit for bit copy? The *only* reason I could imagine, is 
 to *mutate* the original struct...


Yes. That way I could make sure that the class object in the 
struct gets lazily initialized to the same object in both the 
source and the copied struct instance. So in the appender example 
you earlier gave, both app1 and app2 can have the same internal 
object.

But then the source object may not be mutable. I am not a 
compiler expert, but could a special case be made in D compiler 
for the cases where the source struct instance is mutable and is 
made available to ease such lazy initialization?

Regards
- Ritu
Dec 30 2013
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 30.12.2013 12:26, schrieb Ritu:

 Yes. That way I could make sure that the class object in the struct gets
 lazily initialized to the same object in both the source and the copied
 struct instance. So in the appender example you earlier gave, both app1
 and app2 can have the same internal object.

 But then the source object may not be mutable. I am not a compiler
 expert, but could a special case be made in D compiler for the cases
 where the source struct instance is mutable and is made available to
 ease such lazy initialization?

 Regards
 - Ritu



As I already said, the solution is another level of indirection. I had a 
similar discussion with Andrei a while back and he made clear that there 
is no intention in adding any other copy constructor / move constructor. 
Postblit will stay as is.

Kind Regards
Benjamin Thaut
Dec 30 2013
next sibling parent reply "Ritu" <ritu metaprogramming.net> writes:
 As I already said, the solution is another level of indirection.


Well, I do not have a possibility of another level of 
indirection. I am working on a DSL embedded in D. My biggest 
gripe with D is that it does not let me create a struct that 
gives the end user a feeling of native data type. But on the 
other hand we have a lot of capabilities that other languages do 
not have. I believe presently D is the best systems programming 
language to build a DSL in, but it can be easily made much better.

I do not know how to impress Andrei and Walter. I do not even 
know if they are reading this thread.

Regards
- Ritu
Dec 30 2013
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 30 December 2013 at 11:42:52 UTC, Ritu wrote:

 As I already said, the solution is another level of 
 indirection.


 Well, I do not have a possibility of another level of 
 indirection. I am working on a DSL embedded in D. My biggest 
 gripe with D is that it does not let me create a struct that 
 gives the end user a feeling of native data type. But on the 
 other hand we have a lot of capabilities that other languages 
 do not have. I believe presently D is the best systems 
 programming language to build a DSL in, but it can be easily 
 made much better.

 I do not know how to impress Andrei and Walter. I do not even 
 know if they are reading this thread.

 Regards
 - Ritu


What's wrong with "pre-"initializing your data? Surely, there are 
other ways to workaround your problem then having a "2-arg 
postblit". C++ allows CC with a mutable arg. It's been used 
*once* (AFAIK) for auto_ptr, and *that* was deemed a complete 
failure.

There might be usecases were it is legitimately useful, but not 
enough to warrant such a language change.

Have you tried any of the two solution I told you about? "static 
opCall" emulates a default constructor pretty well.

Another solution is simply... pass by ref?
Dec 30 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/30/13 3:29 AM, Benjamin Thaut wrote:

 Am 30.12.2013 12:26, schrieb Ritu:

 Yes. That way I could make sure that the class object in the struct gets
 lazily initialized to the same object in both the source and the copied
 struct instance. So in the appender example you earlier gave, both app1
 and app2 can have the same internal object.

 But then the source object may not be mutable. I am not a compiler
 expert, but could a special case be made in D compiler for the cases
 where the source struct instance is mutable and is made available to
 ease such lazy initialization?

 Regards
 - Ritu



 As I already said, the solution is another level of indirection. I had a
 similar discussion with Andrei a while back and he made clear that there
 is no intention in adding any other copy constructor / move constructor.
 Postblit will stay as is.


Walter is reconsidering that.

Andrei
Dec 30 2013
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 30.12.2013 16:53, schrieb Andrei Alexandrescu:

 On 12/30/13 3:29 AM, Benjamin Thaut wrote:

 As I already said, the solution is another level of indirection. I had a
 similar discussion with Andrei a while back and he made clear that there
 is no intention in adding any other copy constructor / move constructor.
 Postblit will stay as is.


 Walter is reconsidering that.

 Andrei


Oh? Could you give a bit more details on the state of this?

Kind Regards
Benjamin Thaut
Dec 30 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/30/13 7:58 AM, Benjamin Thaut wrote:

 Am 30.12.2013 16:53, schrieb Andrei Alexandrescu:

 On 12/30/13 3:29 AM, Benjamin Thaut wrote:

 As I already said, the solution is another level of indirection. I had a
 similar discussion with Andrei a while back and he made clear that there
 is no intention in adding any other copy constructor / move constructor.
 Postblit will stay as is.


 Walter is reconsidering that.

 Andrei


 Oh? Could you give a bit more details on the state of this?


There's no state. Just that it's an area in which Walter is opened to a 
language change. Kenji is opposed though.

Andrei
Dec 30 2013
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 30.12.2013 17:19, schrieb Andrei Alexandrescu:

 There's no state. Just that it's an area in which Walter is opened to a
 language change. Kenji is opposed though.

 Andrei


I must say, that the current situation with only postblit makes it quite 
easy to implement containers and gives a lot of flexiblity when handling 
user defined value types in general. But as shown in this thread not 
every use case can be implemented with just a postblit. I had some other 
use cases in the past where postblit was not enough, and I had to work 
around by adding one level of indirection. Usually these use cases 
involve wrapping a pointer or a reference to an object.

Kind Regards
Benjamin Thaut
Dec 30 2013
prev sibling parent reply "Ritu" <ritu metaprogramming.net> writes:
 There's no state. Just that it's an area in which Walter is 
 opened to a language change. Kenji is opposed though.

 Andrei



Greetings

I thank Andrei for spending some time on this thread and for 
informing that he and Walter are actively considering extensions 
to the postblit behavior. I take this opportunity to present a 
detailed use case of ours.

We have been working on implementing a Domain Specific Embedded 
Language in D. As is true with most other DSLs, the end users 
would be domain experts and not necessarily expert programmers. 
In our case the DSL we are creating would be useful for modeling 
systems in a specific domain.

I will try to create a small use case here. We want to provide 
our users with a construct called Fifo. A Fifo would be useful to 
enable data exchange between different blocks of the system being 
modeled. Typically a Fifo will allow different agents in the 
system to push or pull data. Additionally we want to enable 
following capabilities with a Fifo construct:

a/ Ability to declare an array (even multidimensional array) or 
Fifo's.
b/ Ability to pass a Fifo to a function argument. Also ability to 
pass an array of Fifos as an argument.
c/ Ability to pass a Fifo to std functions like writeln. In such 
a scenario, the element on the top of the Fifo gets printed.

Let us consider different aspects of providing the Fifo construct:

1. Fifo should be a Struct (not a Class)

A class instance necessarily needs to be initialized. With a 
struct we have possibility of lazy initialization.

2. Fifo initialization

As some forumites have suggested, one option is to force 
initialization at the time of declaration. I do not think this is 
a good option as far as a DSL is concerned. First of all there is 
no way in D (at least I am not aware) to disallow the default 
constructor (the init value must exist). Even for a class object, 
there is no way to keep the end-user away from trying to use null 
objects. Secondly, forcing initialization right at the time of 
declaration might require lots of boiler-plate code. While 
patterns like static opcall initialization may be good for 
programmers, these are not intuitive for the purpose of a DSL. 
Besides consider the amount of boilerplate code required for 
initializing all the Fifos in a 3 dimensional array of Fifos 
(requirement (a) in the list above).

3. Lazy Initialization

Given that explicit initialization may not be good enough, we 
consider lazy initialization. It mostly works, but does not fully 
satisfy requirement (b). An uninitialized Fifo when passed as a 
function argument exhibits totally unexpected behavior.

4. Forcing Fifo argument to be passed as a ref

This may be too difficult to explain to the end-user. To force it 
we may be required to disable the postblit (thereby disabling the 
copy constructor). But when we do that, a lot of other unexpected 
issues come up. For example the std.stdio.writeln expects 
copyable arguments. If we disable postblit, it becomes impossible 
to print the object using writeln (see requirement (c)).


With all these considerations, we need our Fifo to either:

(I) Get implicitly initialized at the time of declaration. This 
will require user-defined default constructor. We understand that 
this is not possible in D. We also understand that this is a 
small sacrifice we make to enable a lot of meta-programming at 
compile time.

OR

(II) Allow postblit to take care of uninitialized lazy Fifo 
instances. For this only we are asking for the ability to access 
and modify the source Fifo instance as well as the copied 
instance in the postblit.

Thanks for bearing with my long rant. As far as I can make out 
neither DIP49 nor DIP53 directly addresses this issue. Let me 
know if I have overlooked some aspects of these DIPs. I and my 
colleague at work are ready to spend time on creating a DIP for 
my use case. I believe it will also be useful for a couple of 
other usecases as well.

Regards
- Ritu
Dec 30 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ritu:


 First of all there is no way in D (at least I am not aware) to 
 disallow the default constructor (the init value must exist).


Do you mean something like this?


struct Foo {
      disable this();
     this(int) {}
}
void main() {
     // Foo f1; // Error
     auto f2 = Foo(1);
}


Or do you mean this?

struct Bar {}
void main() {
     Bar b = void;
}


Bye,
bearophile
Dec 30 2013
parent reply "Ritu" <ritu metaprogramming.net> writes:
 Do you mean something like this?


 struct Foo {
      disable this();
     this(int) {}
 }
 void main() {
     // Foo f1; // Error
     auto f2 = Foo(1);
 }



Thanks Beorophile. I somehow overlooked  disable for default 
constructor. But I hope that you get the larger picture. Imagine 
an end-user wanting to create an array of Fifos. In a DSL, it 
does not come out nice if you ask him to initialize all the Fifo 
elements.

My rant boils down to this. To have the ability to create "native 
like" data in any DSL embedded in D, we need one of the following 
three:

1. The ability to have a user-defined default constructor for 
structs. I believe this is not possible since it does not go well 
with D's metaprogramming.
2. Some sort of preblit. That also is not possible since it boils 
down to having a default constructor.
3. Allowing postblit to access and modify both the source and 
target struct instances in a postblit.

The last two of these options rely on lazy initialization which 
works fine except for the situation wherein you pass an 
uninitialized struct instance to a function. Also I believe "lazy 
initialization" is a pattern used often in D containers. And the 
postblit enhancement I am asking for helps take care of the 
unexpected behavior that shows up with those container classes 
too.

Regards
- Ritu
Dec 30 2013
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 31 December 2013 at 02:28:45 UTC, Ritu wrote:

 1. The ability to have a user-defined default constructor for 
 structs. I believe this is not possible since it does not go 
 well with D's metaprogramming.


If this is for a DSL, can't you make it so situations that lower 
to default construction use a function initializer? It would be 
completely opaque from the user's perspective. I don't think 
language details should ever be relevant to a DSL; it seems to me 
that you should always be able to work around it.

Sorry if this is impractical, I haven't read the thread super 
closely.
Dec 31 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2013 7:53 AM, Andrei Alexandrescu wrote:

 Walter is reconsidering that.


<cough><cough>
Dec 30 2013
prev sibling parent reply "Ritu" <ritu metaprogramming.net> writes:
 But then the source object may not be mutable. I am not a 
 compiler expert, but could a special case be made in D compiler 
 for the cases where the source struct instance is mutable and 
 is made available to ease such lazy initialization?



I am suggesting a DIP here.

Could the postblit take two arguments and make the source object 
available for possible mutation? We could have two variants of 
the postblit and the one with two arguments (source and 
destination *this* pointers) could be applied only to the cases 
where the source struct instance is mutable. And the normal 
postblit (in the form we have now) could apply to the cases where 
the source struct instance is immutable. As I said, I am not a 
compiler expert and I do not know if what I am saying makes sense.

Regards
- Ritu
Dec 30 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/30/13 3:34 AM, Ritu wrote:

 But then the source object may not be mutable. I am not a compiler
 expert, but could a special case be made in D compiler for the cases
 where the source struct instance is mutable and is made available to
 ease such lazy initialization?



 I am suggesting a DIP here.


Did you take a look at http://wiki.dlang.org/DIP49 and 
http://wiki.dlang.org/DIP53?

Andrei
Dec 30 2013
parent "Ritu" <ritu metaprogramming.net> writes:
On Monday, 30 December 2013 at 16:10:35 UTC, Andrei Alexandrescu 
wrote:

 On 12/30/13 3:34 AM, Ritu wrote:

 But then the source object may not be mutable. I am not a 
 compiler
 expert, but could a special case be made in D compiler for 
 the cases
 where the source struct instance is mutable and is made 
 available to
 ease such lazy initialization?



 I am suggesting a DIP here.


 Did you take a look at http://wiki.dlang.org/DIP49 and 
 http://wiki.dlang.org/DIP53?

 Andrei


I have done that now. These DIPs though related, do not make the 
original object available for modification. But since DIP49 
allows qualification of postblit, I believe what I am asking for 
becomes very much possible as an extension. We just need to 
provide another overloaded "mutable" postblit that would provide 
access to the "original" as well as "copied" struct instances.

I believe this will go a long way in fixing the behavior of some 
containers like the appender too. In general it will make "lazy 
initialization" much more usable in D.

Regards
- Ritu
Dec 30 2013
prev sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 29 December 2013 at 19:26:09 UTC, monarch_dodra wrote:

 Nope. What you are asking for is basically a default 
 constructor, which D does not provide. Workarounds include the 
 "static opCall" pattern, as well as the "function builder" 
 pattern (eg: "MyStruct myStruct(Args args)")


Actually it does provide, but does not allow to override it. When 
you define postblit, dmd generates default constructor like this:

struct S
{
    int data[];
    this(this) { data = data.dup; }
    void __cpctor(const ref S s) const
    {
       this = s;
       s.__postblit();
    }
}

The only way to override it is currently is to make your 
function, drop original symbol from binary file and link the 
program.
I think it could work like opAssign - provide default version but 
allow to place yours. In such case it would be possible to alter 
original struct object but it would lead to conflict if original 
object is const or immutable qualified.
Dec 30 2013
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 30 December 2013 at 16:18:22 UTC, Maxim Fomin wrote:

 On Sunday, 29 December 2013 at 19:26:09 UTC, monarch_dodra 
 wrote:

 Nope. What you are asking for is basically a default 
 constructor, which D does not provide. Workarounds include the 
 "static opCall" pattern, as well as the "function builder" 
 pattern (eg: "MyStruct myStruct(Args args)")


 Actually it does provide, but does not allow to override it. 
 When you define postblit, dmd generates default constructor 
 like this:

 struct S
 {
    int data[];
    this(this) { data = data.dup; }
    void __cpctor(const ref S s) const
    {
       this = s;
       s.__postblit();
    }
 }

 The only way to override it is currently is to make your 
 function, drop original symbol from binary file and link the 
 program.
 I think it could work like opAssign - provide default version 
 but allow to place yours. In such case it would be possible to 
 alter original struct object but it would lead to conflict if 
 original object is const or immutable qualified.


Hum... The original question was "Any possibility of *preblit* 
kind functionality?". I meant "default constructor" in the C++ 
sense: A constructor that gets called with no arguments. That 
does not exist in D.

I did not know dmd generated an actual symbol for CC though. 
Interesting to know.
Dec 30 2013
prev sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 29 December 2013 at 16:22:04 UTC, Ritu wrote:

 I have a struct that wraps a class object and lazily 
 initializes it. Now in case the struct instance is passed as an 
 argument to a function and it has not been initialized yet, the 
 default copy constructor and the postblit do not offer a 
 possibility to initialize the class object before copying.


Why this is a problem? You can create function which return class 
field from struct wrapper and make such function alias this, in 
addition postblit should allocate new class. The fact that 
original struct may have null value is irrelevant if copying is 
made correctly.
Dec 29 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 29 December 2013 at 18:40:07 UTC, Maxim Fomin wrote:

 On Sunday, 29 December 2013 at 16:22:04 UTC, Ritu wrote:

 I have a struct that wraps a class object and lazily 
 initializes it. Now in case the struct instance is passed as 
 an argument to a function and it has not been initialized yet, 
 the default copy constructor and the postblit do not offer a 
 possibility to initialize the class object before copying.


 Why this is a problem? You can create function which return 
 class field from struct wrapper and make such function alias 
 this, in addition postblit should allocate new class. The fact 
 that original struct may have null value is irrelevant if 
 copying is made correctly.


It's a problem for "reference semantic structs" that need to be 
initialized. This is actually a "well know" and often encountered 
problem.

It strikes things like Appende, Array, and also built in AA's.

void foo(Appender!(int[]) app)
{
     app.put(1);
}

void main()
{
     Appender!(int[]) app1;
     Appender!(int[]) app2 = appender!(int[]);
     foo(app1);
     foo(app2);
     assert(app1.data == [1]); //Fails
     assert(app2.data == [1]); //Passes
}
Dec 29 2013
parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 29 December 2013 at 19:22:51 UTC, monarch_dodra wrote:

 On Sunday, 29 December 2013 at 18:40:07 UTC, Maxim Fomin wrote:

 Why this is a problem? You can create function which return 
 class field from struct wrapper and make such function alias 
 this, in addition postblit should allocate new class. The fact 
 that original struct may have null value is irrelevant if 
 copying is made correctly.


 It's a problem for "reference semantic structs" that need to be 
 initialized. This is actually a "well know" and often 
 encountered problem.


Yes, I forgot about this sort of troubles.
Dec 30 2013