If you don't want to get the great PITA, never create temporary objects in function parameters.
I recently spent a whole day digging through my reference counted containers library. But nasty bug was not there, but in the compiler.

Look at this: https://glot.io/snippets/eui2l8ov0r

Result:
> Bar.this(int): 7FFD3D60CD38
> fun: 7FFD3D60CD20
> Bar.~this(): 7FFD3D60CD20

Compiler creates struct on the stack and silently (without postblitting and destruction old object) moves it to another address. Is it normal? I don't think so.

But that's not the most fun.

Look at this: https://glot.io/snippets/eui2pjrwvi

Result:
> Bar.this(int): 7FFF87DD2D31
> fun: 7FFF87DD2CE0
> Bar.~this(): 7FFF87DD2CE0
> Bar.~this(): 7FFF87DD2D31

WAT??? Compiler creates struct on the stack copies it without postblitting and destructs both objects.

But if you create the structure before calling the function, then all will be well:
https://glot.io/snippets/eui2vn2bu1

All this greatly angered me because there are several issues related wrong struct construction and destruction in the bugtracker. Because of these bugs my low level libraries full of strange hacks.

I want to ask. How you guys are going to create a reliable RC library, if such fundamental bugs hang in the issue tracker for months and years. And instead of fixing them, you develop new minor bells and whistles.

See: https://issues.dlang.org/buglist.cgi?quicksearch=destructor

Since I myself can't fix such bugs (my knowledge in this area are extremely small), I have a question to Andrei Alexandrescu:
Can I donate to the D Foundation and that my donations would be aimed at fixing exactly these bugs?

Jack Applegame wrote:

> Compiler creates struct on the stack and silently (without postblitting and destruction old object) moves it to another address. Is it normal?
yes.

> WAT??? Compiler creates struct on the stack copies it without postblitting and destructs both objects.
and this is the real bug.

On Friday, 13 October 2017 at 10:35:56 UTC, Jack Applegame wrote:
> Compiler creates struct on the stack and silently (without postblitting and destruction old object) moves it to another address. Is it normal? I don't think so.

It is. Structs have no identity, and the compiler/GC/whatever is free to copy and/or move them about as it sees fit (as long as there is ostensibly only one - no duplicate constructor/destructor calls, no desynching of state). That's why the documentation[1] says not to have internal pointers in structs.

> WAT??? Compiler creates struct on the stack copies it without postblitting and destructs both objects.

Now this looks like a real bug. There should be a this(this) call in there.

> Can I donate to the D Foundation and that my donations would be aimed at fixing exactly these bugs?

BountySource[2] lets you do basically exactly that.

[1]: https://dlang.org/spec/garbage.html, "Do not have pointers in a struct instance that point back to the same instance."

[2]: https://www.bountysource.com/

On Friday, 13 October 2017 at 11:21:48 UTC, Biotronic wrote:
> BountySource[2] lets you do basically exactly that.
My experience says that BountySource almost doesn't help.

On Friday, 13 October 2017 at 10:35:56 UTC, Jack Applegame wrote:
> If you don't want to get the great PITA, never create temporary objects in function parameters.
> I recently spent a whole day digging through my reference counted containers library. But nasty bug was not there, but in the compiler.
>
> Look at this: https://glot.io/snippets/eui2l8ov0r
>
> Result:
>> Bar.this(int): 7FFD3D60CD38
>> fun: 7FFD3D60CD20
>> Bar.~this(): 7FFD3D60CD20
>
> Compiler creates struct on the stack and silently (without postblitting and destruction old object) moves it to another address. Is it normal? I don't think so.
>
> But that's not the most fun.
>
> Look at this: https://glot.io/snippets/eui2pjrwvi
>
> Result:
>> Bar.this(int): 7FFF87DD2D31
>> fun: 7FFF87DD2CE0
>> Bar.~this(): 7FFF87DD2CE0
>> Bar.~this(): 7FFF87DD2D31
>
> WAT??? Compiler creates struct on the stack copies it without postblitting and destructs both objects.
>
> But if you create the structure before calling the function, then all will be well:
> https://glot.io/snippets/eui2vn2bu1
>
> All this greatly angered me because there are several issues related wrong struct construction and destruction in the bugtracker. Because of these bugs my low level libraries full of strange hacks.
>
> I want to ask. How you guys are going to create a reliable RC library, if such fundamental bugs hang in the issue tracker for months and years. And instead of fixing them, you develop new minor bells and whistles.
>
> See: https://issues.dlang.org/buglist.cgi?quicksearch=destructor
>
> Since I myself can't fix such bugs (my knowledge in this area are extremely small), I have a question to Andrei Alexandrescu:
> Can I donate to the D Foundation and that my donations would be aimed at fixing exactly these bugs?

Interesting. If you remove the CTor in Foo it works again.

On Friday, 13 October 2017 at 12:03:55 UTC, Dgame wrote:
> Interesting. If you remove the CTor in Foo it works again.
If you remove DTor it works again too. :)

On Friday, 13 October 2017 at 12:08:00 UTC, Jack Applegame wrote:
> On Friday, 13 October 2017 at 12:03:55 UTC, Dgame wrote:
>> Interesting. If you remove the CTor in Foo it works again.
> If you remove DTor it works again too. :)

That's one of these times where it would be helpful to see the generated AST.

On 10/13/17 8:56 AM, Dgame wrote:
> On Friday, 13 October 2017 at 12:08:00 UTC, Jack Applegame wrote:
>> On Friday, 13 October 2017 at 12:03:55 UTC, Dgame wrote:
>>> Interesting. If you remove the CTor in Foo it works again.
>> If you remove DTor it works again too. :)
> 
> That's one of these times where it would be helpful to see the generated AST.

dmd has this feature: -vcg-ast.

I already have tried it, and looks like there is no call to the dtor that matches the output.

I think it's a bug in the compiler.

-Steve

On Friday, 13 October 2017 at 11:21:48 UTC, Biotronic wrote:
> On Friday, 13 October 2017 at 10:35:56 UTC, Jack Applegame wrote:
>> Compiler creates struct on the stack and silently (without postblitting and destruction old object) moves it to another address. Is it normal? I don't think so.
>
> It is. Structs have no identity, and the compiler/GC/whatever is free to copy and/or move them about as it sees fit (as long as there is ostensibly only one - no duplicate constructor/destructor calls, no desynching of state). That's why the documentation[1] says not to have internal pointers in structs.
>
>> WAT??? Compiler creates struct on the stack copies it without postblitting and destructs both objects.
>
> Now this looks like a real bug. There should be a this(this) call in there.
>
>> Can I donate to the D Foundation and that my donations would be aimed at fixing exactly these bugs?
>
> BountySource[2] lets you do basically exactly that.
>
> [1]: https://dlang.org/spec/garbage.html, "Do not have pointers in a struct instance that point back to the same instance."
>
> [2]: https://www.bountysource.com/

What are the advantages of this weird behavior ?
Also if the object is finally moved then why to call ctor not on the moved object ?
[1] states that i cannot save the pointer inside the struct on the same struct(because GC can move objects in the memory, but in the example there's no gc as objects are on the stack), but what if i put &this to some global variable ? It should work as expected, not being partly moved. Postblit should be called as well as dtor of original object.

1 is a definitely a bug.

On Friday, 13 October 2017 at 11:54:38 UTC, Jack Applegame wrote:
> On Friday, 13 October 2017 at 11:21:48 UTC, Biotronic wrote:
>> BountySource[2] lets you do basically exactly that.
> My experience says that BountySource almost doesn't help.

It works if the bounty is worth someone sacrificing their free time to do the work.  For example, I'd attempt fixing the bug if the bounty were greater than $200, but I don't know if I'd be successful, as I've only just started working working with the DMD source code.

It would be nice if the D Foundation would do some kind of creative incentivizing, such as prioritizing bugs, and matching bounty contributions.

But even then, you might run the risk of the work being done, but having the PR sit in purgatory for an indeterminate length of time.

I'm not at all happy with the way D is managed, but I'm also lacking any actionable solutions.

Mike