> 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

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...

> 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

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

> 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

> 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

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?

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

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

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.