Bug 6186

[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:
>
> 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