On 09.06.20 17:11, 12345swordy wrote:
> ...
> 
> An idea that show no progress for what? Two years? I am losing my patience with this already. I can't consider d to be a serious language if this bug won't be fix in some reasonable time frame in the future.
> 
> -Alex

I am not sure what you hope to accomplish with this rhetoric. There seems to be a recent surge in people assuming that people contribute to the language because they want it to be "popular"/"serious"/...
I highly doubt that this is the case and those messages clutter the forums without adding anything interesting to discussions.

On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
> On 09.06.20 17:11, 12345swordy wrote:
>> ...
>> 
>> An idea that show no progress for what? Two years? I am losing my patience with this already. I can't consider d to be a serious language if this bug won't be fix in some reasonable time frame in the future.
>> 
>> -Alex
>
> I am not sure what you hope to accomplish with this rhetoric. There seems to be a recent surge in people assuming that people contribute to the language because they want it to be "popular"/"serious"/...
> I highly doubt that this is the case and those messages clutter the forums without adding anything interesting to discussions.

This is the first bug that I had encounter first hand when programming in d. An bug that hasn't been fixed in years!

It can be fix by having the druntime providing a interface say "Dispose" and just have the destroy function call that and leave the old deconstructors alone.

The fix itself is heavily inspired by c# language.
https://docs.microsoft.com/en-us/dotnet/api/system.idisposable.dispose?view=netcore-3.1

On Tuesday, 9 June 2020 at 15:45:29 UTC, 12345swordy wrote:

> It can be fix by having the druntime providing a interface say "Dispose" and just have the destroy function call that and leave the old deconstructors alone.

There's no need for a new interface. What needs to happen is resolution of [1] and amendment to destroy() so it avoids rt_finalize and infers correct attributes. Which, even three years later, I maintain should be resolved by disallowing classes to loosen destructor attributes.

[1] https://issues.dlang.org/show_bug.cgi?id=15246

Until that happens, locally, in your own codebase, you can just have your own variant of destroy() that infers attributes as weakest of all in a given hierarchy. Provided you don't write classes that violate dtor attributes down the inheritance chain.
So at least this problem can be sidestepped, though I agree it should have a formal resolution in the language and the runtime library.

On 09.06.20 17:45, 12345swordy wrote:
> On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
>> On 09.06.20 17:11, 12345swordy wrote:
>>> ...
>>>
>>> An idea that show no progress for what? Two years? I am losing my patience with this already. I can't consider d to be a serious language if this bug won't be fix in some reasonable time frame in the future.
>>>
>>> -Alex
>>
>> I am not sure what you hope to accomplish with this rhetoric. There seems to be a recent surge in people assuming that people contribute to the language because they want it to be "popular"/"serious"/...
>> I highly doubt that this is the case and those messages clutter the forums without adding anything interesting to discussions.
> 
> This is the first bug that I had encounter first hand when programming in d. An bug that hasn't been fixed in years!
> 
> It can be fix by having the druntime providing a interface say "Dispose" and just have the destroy function call that and leave the old deconstructors alone.
> 
> The fix itself is heavily inspired by c# language.
> https://docs.microsoft.com/en-us/dotnet/api/system.idisposable.dispose?view=netcore-3.1 
> 
I don't think that's necessary. Destructors should just inherit the base class destructor's attributes, then `destroy` can annotate itself with appropriate attributes.

Also see: https://issues.dlang.org/show_bug.cgi?id=20914

On Tuesday, 9 June 2020 at 16:43:21 UTC, Timon Gehr wrote:
> On 09.06.20 17:45, 12345swordy wrote:
>> On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
>>> [...]
>> 
>> This is the first bug that I had encounter first hand when programming in d. An bug that hasn't been fixed in years!
>> 
>> It can be fix by having the druntime providing a interface say "Dispose" and just have the destroy function call that and leave the old deconstructors alone.
>> 
>> The fix itself is heavily inspired by c# language.
>> https://docs.microsoft.com/en-us/dotnet/api/system.idisposable.dispose?view=netcore-3.1
>> 
> I don't think that's necessary. Destructors should just inherit the base class destructor's attributes, then `destroy` can annotate itself with appropriate attributes.
>
> Also see: https://issues.dlang.org/show_bug.cgi?id=20914
Which in order for that to happen it needs to be virtual function, not a static function.

On 6/9/20 8:12 PM, 12345swordy wrote:
> On Tuesday, 9 June 2020 at 16:43:21 UTC, Timon Gehr wrote:
>> On 09.06.20 17:45, 12345swordy wrote:
>>> On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
>>>> [...]
>>>
>>> This is the first bug that I had encounter first hand when programming in d. An bug that hasn't been fixed in years!
>>>
>>> It can be fix by having the druntime providing a interface say "Dispose" and just have the destroy function call that and leave the old deconstructors alone.
>>>
>>> The fix itself is heavily inspired by c# language.
>>> https://docs.microsoft.com/en-us/dotnet/api/system.idisposable.dispose?view=netcore-3.1 
>>>
>>>
>> I don't think that's necessary. Destructors should just inherit the base class destructor's attributes, then `destroy` can annotate itself with appropriate attributes.
>>
>> Also see: https://issues.dlang.org/show_bug.cgi?id=20914
> Which in order for that to happen it needs to be virtual function, not a static function.

No, that's also not necessary. You can inherit attributes without making the function defined by the destructor function declaration virtual. __xdtor still needs to be virtual, but that appears to be the case already.

On Tuesday, 9 June 2020 at 18:47:13 UTC, Timon Gehr wrote:
> On 6/9/20 8:12 PM, 12345swordy wrote:
>> On Tuesday, 9 June 2020 at 16:43:21 UTC, Timon Gehr wrote:
>>> On 09.06.20 17:45, 12345swordy wrote:
>>>>[...]
>>> I don't think that's necessary. Destructors should just inherit the base class destructor's attributes, then `destroy` can annotate itself with appropriate attributes.
>>>
>>> Also see: https://issues.dlang.org/show_bug.cgi?id=20914
>> Which in order for that to happen it needs to be virtual function, not a static function.
>
> No, that's also not necessary. You can inherit attributes without making the function defined by the destructor function declaration virtual. __xdtor still needs to be virtual, but that appears to be the case already.

How exactly? By having attributes themselves check the attributes for the parent class of the deconstructor?

On Tuesday, 9 June 2020 at 18:57:41 UTC, 12345swordy wrote:

>>> Which in order for that to happen it needs to be virtual function, not a static function.
>>
>> No, that's also not necessary. You can inherit attributes without making the function defined by the destructor function declaration virtual. __xdtor still needs to be virtual, but that appears to be the case already.
>
> How exactly? By having attributes themselves check the attributes for the parent class of the deconstructor?

Attributes can't check anything, they're attributes :) The compiler should statically check your destructor against those of members (if any) and a paren't class (which has already gone through the same check). I.e. you simply shouldn't be allowed to derive a class that has less strict attributes than the most strict intersection of the above. If any member has a @nogc destructor, the class would have to have a @nogc destructor as well. Same if a parent has a @nogc destructor.
This way would ensure that you could destroy objects of derived classes even via a reference to base class without violating attributes, as such class definition simply would not have compiled.

On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
> On 09.06.20 17:11, 12345swordy wrote:

> There seems to be a recent surge in people assuming that people contribute to the language because they want it to be "popular"/"serious"/...
> I highly doubt that this is the case and those messages clutter the forums without adding anything interesting to discussions.

Isn't this way of thinking in itself a problem. How is it any different from bashing Walter for things he's not personally interested in?

His complaints wasn't worded out well but you just blew it all over the place.

On 10.06.20 02:46, aberba wrote:
> On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
>> On 09.06.20 17:11, 12345swordy wrote:
> 
>> There seems to be a recent surge in people assuming that people contribute to the language because they want it to be "popular"/"serious"/...
>> I highly doubt that this is the case and those messages clutter the forums without adding anything interesting to discussions.
> 
> Isn't this way of thinking in itself a problem.

Probably no, but I am not sure which "way of thinking" or what kind of "problem" you are referring to.

> How is it any different from bashing Walter for things he's not personally interested in?
> ...

What is "it" and why does it have to be different?

> His complaints wasn't worded out well...
> 

It was worded out in a way that likely does not encourage potential contributors to work on his issue. I just pointed that out and noted that he is not the only one who has been doing that recently.

> but you just blew it all over the place.

Again, I am not sure what you are trying to say, nor why your reaction is warranted.