On Monday, 16 October 2017 at 03:29:03 UTC, Michael V. Franklin wrote:

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

In fact, you might want to propose matching bounty from the community on this specific bug to encourage funding.  For example, make an announcement on the forum that anyone who places a bounty on the bug in question will receive a matching contribution from you.  Maybe that might raise the bounty high enough to get someone qualified to fix the bug.  Or maybe not; it's just an idea that occurred to me.

Mike

Michael V. Franklin wrote:

> In fact, you might want to propose matching bounty from the community on this specific bug to encourage funding.  For example, make an announcement on the forum that anyone who places a bounty on the bug in question will receive a matching contribution from you.  Maybe that might raise the bounty high enough to get someone qualified to fix the bug.  Or maybe not; it's just an idea that occurred to me.

judging from my several decades of expirience, bounties almost never works. there are alot of reasons for that, but the fact still stands: it is *almost* impossible to make something happen with boundy. it may work by accident ;-), but i myself wouldn't count on that. either bounty is too small ("hey, my time worth much more! i'd better spend it playing videogames!"), or it is too big ("hey, this is a Really Huge Problem, if somebody wants to pay than much! that means that i'll inevitably spend more time on that, and... the bounty is too small. oops." ;-).

but one can hire a contractor to fix some specific problem. this is much easier, and almost usually works as people expected: there are clearly specified goals, a payment, a timeline and such. both parties know what exactly they want, and can control the whole process.

On Monday, 16 October 2017 at 03:49:18 UTC, ketmar wrote:
> Michael V. Franklin wrote:
>
>> [...]
>
> judging from my several decades of expirience, bounties almost never works. there are alot of reasons for that, but the fact still stands: it is *almost* impossible to make something happen with boundy. it may work by accident ;-), but i myself wouldn't count on that. either bounty is too small ("hey, my time worth much more! i'd better spend it playing videogames!"), or it is too big ("hey, this is a Really Huge Problem, if somebody wants to pay than much! that means that i'll inevitably spend more time on that, and... the bounty is too small. oops." ;-).
>
> [...]

True, that's how Eric Niebler gets to work on Range V1, V2, V3 as he was the only hired programmer by ISO CPP.

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?

Is this a bug?
Reading the chapter "7.1.3.5 They Whys of this(this)" in my D Programming Language book it says that the compiler is free to elide the call to this(this) when it can prove that the source of the copy will not be used after the call.

The explanations there make some sense to me.

Is this actually working as intended? (Just not how you'd hope it works)?

On 10/17/17 12:27 PM, John Burton wrote:
> 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?
> 
> Is this a bug?
> Reading the chapter "7.1.3.5 They Whys of this(this)" in my D Programming Language book it says that the compiler is free to elide the call to this(this) when it can prove that the source of the copy will not be used after the call.

It is allowed to, yes, and it should in this case.

> The explanations there make some sense to me.
> 
> Is this actually working as intended? (Just not how you'd hope it works)?

No, if a postblit is called, then an equivalent destructor should be called as well. The number of constructors + postblit calls should equal the number of destructor calls. Otherwise, you can't do things reliably like reference counting.

In this case, an extra destructor call is made without a corresponding postblit or constructor.

-Steve

On Tuesday, 17 October 2017 at 19:00:38 UTC, Steven Schveighoffer wrote:

> In this case, an extra destructor call is made without a corresponding postblit or constructor.
>
> -Steve

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