https://issues.dlang.org/show_bug.cgi?id=14078
--- Comment #4 from [email protected] --- (In reply to Ketmar Dark from comment #3) > (In reply to rswhite4 from comment #2) > > (In reply to Ketmar Dark from comment #1) > > > `emplace` is not a built-in. one can write alot of emplace-like functions > > > that allocates any memory for the object. even the function named > > > `emplace`, > > > that will sometimes allocates on stack and sometimes uses `malloc()`. > > > > > > what you actually asking is compiler that is able to use some AI to see > > > what > > > programmer *means* by writing the code. this is not possible. > > > > No. The compiler should be able to detect that a2 is stack allocated (the > > compiler should be able to see the type of a2 -> A and also that the memory > > is on the stack). > compiler doesn't know what `emplace` does. to determine that it have to > switch on secret AI button somehow. can you please show a sample code that > is able to determine such things in all cases? 'cause if some cases are > missed, then there will be no way for programmer to determine when > destructor will be called and when not. > I'm not talking about emplace. That is completely irrelevant. My thought was that the compiler should recognize that a2 is stack allocated and therefore call the dtor. Therefore the label "enhancement". > > But your example with malloc could be true, but I'm sure that the DTor of a2 > > should be called at least at the end of the programm. The compiler should be > > able to do that, even without any AI. ;) > class dtors are not guaranteed to be called at all. if someone will change > GC so it will stop calling dtors, it will break nothing by the specs. and > this is not an oversight. That is new to me. Ok, then it is probably impossible. I thought at least it would be helpful to call all remaining dtors at the end of the program. If that is not desired I will close this issue. > > > if you want stack-allocated classes with automatic dtors, why don't use > > > `std.typecons.scoped`? > > > > It is IMO not well implemented. > please, can you show the cases where it's not working, so we can fill > bugreports and somebody will fix it? Look at the code. One thing is that the buffer is overproportional. But that is not the topic. --
