> This has been acknowledged. Yes, removing delete in D2 will break > compatibility with existing code. However, I'm sure that at an early > stage, the compiler will probably issue error messages once it > encounters delete statements, for which the fix is quite easy: just > remove them, and recompile. As an unfortunate side effect, a few other > problems might occur, especially for shared objects. But refactoring to > a simpler system, in which the garbage collector is trusted to manage > the heap, should be easy.
Yes, I was speaking generally here about "breaking compatibility" philosophy. I agree that delete probably will not be such problem - but I would prefer mark features deprecated before it will be really removed and write only warning when compiled - in case it is possible. (For example some datatype was removed in d2 (bit? - I am not sure) which is one of error messages which I get when I try compile my project with incompatible library) People don't have to know what is planned for removing. Moreover there is not complete list of changes in d2. Or is?
