Re: Bug 6186
02.10.2013 23:03, Benjamin Thaut пишет: Am 02.10.2013 20:56, schrieb H. S. Teoh: On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote: Well thats the problem with volenteer work. People usually pick something they interrested in. (Kenji beeing an exception to this rule) The most annoying struct lifetime bug for me is the following: http://d.puremagic.com/issues/show_bug.cgi?id=8360 So Kenji rapidly (as often) did https://github.com/D-Programming-Language/dmd/pull/2620 Let's be astonished by his response time! -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Bug 6186
On Thursday, 3 October 2013 at 06:25:04 UTC, Denis Shelomovskij wrote: 02.10.2013 23:03, Benjamin Thaut пишет: Am 02.10.2013 20:56, schrieb H. S. Teoh: On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote: Well thats the problem with volenteer work. People usually pick something they interrested in. (Kenji beeing an exception to this rule) The most annoying struct lifetime bug for me is the following: http://d.puremagic.com/issues/show_bug.cgi?id=8360 So Kenji rapidly (as often) did https://github.com/D-Programming-Language/dmd/pull/2620 Let's be astonished by his response time! Don't think I'll ever stop. Post a bug - fix within hours. Look at github notifications - several pulls by Kenji.
Bug 6186
http://d.puremagic.com/issues/show_bug.cgi?id=6186 This bug is open since two years and nothing has happend so far. If you look at it its really funny: Kenji: Heres a Bug and a fix Walter: I don't like your fix but I don't have a better idea Kenji: closes pull request -- silence -- (for over 2 years) We should really find a solution for this problem. Kind Regards Benjamin Thaut
Re: Bug 6186
On Wednesday, 2 October 2013 at 18:06:45 UTC, Benjamin Thaut wrote: http://d.puremagic.com/issues/show_bug.cgi?id=6186 This bug is open since two years and nothing has happend so far. If you look at it its really funny: Kenji: Heres a Bug and a fix Walter: I don't like your fix but I don't have a better idea Kenji: closes pull request -- silence -- (for over 2 years) We should really find a solution for this problem. Kind Regards Benjamin Thaut For me the bug is invalid since out parameter is implicitly ref and it has nothing to do with initialization (you better think about it as an assignment). This means there are no reasons to call destructor.
Re: Bug 6186
Am 02.10.2013 20:23, schrieb Maxim Fomin: For me the bug is invalid since out parameter is implicitly ref and it has nothing to do with initialization (you better think about it as an assignment). This means there are no reasons to call destructor. In my eyes the bug is clearly not invalid because it caused memory leaks for me. If you have a struct which is a wrapper to a malloced buffer, and you pass it to a function which takes the struct as out parameter, the destructor will never be called because the memory will simply be reinitialized and the memory will leak. In my eyes this is a clear struct lifetime bug.
Re: Bug 6186
If the given argument to the out parameter is not correctly initialized (eg. void initialized variable), calling dtor for the argument is absolutely unsafe. That's the reason why my patch was rejected by Walter. Alternative language semantics in my thought is: --- If an out parameter typed T exists, and 1. T has elaborate destructor 2. T.init represents logically invalid object (T is nested struct, and/or T has @disable this();) Automatic blit initializing for the out parameter would be unsafe. So semantic analysis would reject such a out parameter declaration. --- But I'm still not sure the rule is enough useful for many cases... Kenji Hara 2013/10/3 Benjamin Thaut c...@benjamin-thaut.de http://d.puremagic.com/issues/**show_bug.cgi?id=6186http://d.puremagic.com/issues/show_bug.cgi?id=6186 This bug is open since two years and nothing has happend so far. If you look at it its really funny: Kenji: Heres a Bug and a fix Walter: I don't like your fix but I don't have a better idea Kenji: closes pull request -- silence -- (for over 2 years) We should really find a solution for this problem. Kind Regards Benjamin Thaut
Re: Bug 6186
On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote: Am 02.10.2013 20:23, schrieb Maxim Fomin: For me the bug is invalid since out parameter is implicitly ref and it has nothing to do with initialization (you better think about it as an assignment). This means there are no reasons to call destructor. In my eyes the bug is clearly not invalid because it caused memory leaks for me. If you have a struct which is a wrapper to a malloced buffer, and you pass it to a function which takes the struct as out parameter, the destructor will never be called because the memory will simply be reinitialized and the memory will leak. In my eyes this is a clear struct lifetime bug. I agree. This is one area of D that I'm not very impressed with, actually. It is a minefield full of hazards. Once your type has a dtor, you can expect to run into a lot of similar bugs everwhere -- dtors not getting called at the right places, can't up them in an AA without hitting bugs, unclear semantics of when/where/how dtors should be called, unclear semantics on state of member variables, etc.. Just witness, e.g., the issues we have with emplace and destroy. I suspect it's because most D code doesn't use dtors, or only uses them in very limited contexts, so dtor-related code is not well-tested. I wish these issues can be addressed with a consistent approach rather than the current ad hoc approach of there's a fire here let's put in this hack to fix it, there's another fire over there but we don't know what to do so we're just going to ignore it. But it doesn't seem to be the priority right now. :-( T -- Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
Re: Bug 6186
Am 02.10.2013 20:43, schrieb Kenji Hara: If the given argument to the out parameter is not correctly initialized (eg. void initialized variable), calling dtor for the argument is absolutely unsafe. That's the reason why my patch was rejected by Walter. Alternative language semantics in my thought is: --- If an out parameter typed T exists, and 1. T has elaborate destructor 2. T.init represents logically invalid object (T is nested struct, and/or T has @disable this();) Automatic blit initializing for the out parameter would be unsafe. So semantic analysis would reject such a out parameter declaration. --- But I'm still not sure the rule is enough useful for many cases... Kenji Hara I would also be fine with a out paramter always getting rejected as soon as T has a destructor. For such cases a easy fix would be to just replace out with ref. I actually grep-ed my whole codebase and replaced all out with ref because of this bug.
Re: Bug 6186
Am 02.10.2013 20:56, schrieb H. S. Teoh: On Wed, Oct 02, 2013 at 08:26:22PM +0200, Benjamin Thaut wrote: I agree. This is one area of D that I'm not very impressed with, actually. It is a minefield full of hazards. Once your type has a dtor, you can expect to run into a lot of similar bugs everwhere -- dtors not getting called at the right places, can't up them in an AA without hitting bugs, unclear semantics of when/where/how dtors should be called, unclear semantics on state of member variables, etc.. Just witness, e.g., the issues we have with emplace and destroy. I suspect it's because most D code doesn't use dtors, or only uses them in very limited contexts, so dtor-related code is not well-tested. I wish these issues can be addressed with a consistent approach rather than the current ad hoc approach of there's a fire here let's put in this hack to fix it, there's another fire over there but we don't know what to do so we're just going to ignore it. But it doesn't seem to be the priority right now. :-( T Well thats the problem with volenteer work. People usually pick something they interrested in. (Kenji beeing an exception to this rule) The most annoying struct lifetime bug for me is the following: http://d.puremagic.com/issues/show_bug.cgi?id=8360 I have a rcstring struct that internally ref-counts the string memory. Because of this bug I can not write assert(condition, myFormat(%d, i).str()); because it will explode. I always have to remember writing: auto error1 = myFormat(%d, i); assert(condition, error1.str()); which will work correctly. Kind Regards Benjamin Thaut
