A few general thoughts

[Don]

Daniel Gibson wrote:
> Am 29.04.2011 12:11, schrieb lenochware:
>>> 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?
> 
> Who said that delete will not be marked deprecated before it's removed?

Take a lesson from history:
-----------
What's New for D 0.116
Mar 7, 2005
New/Changed Features

$ can now be used instead of length inside an array's []. It represents 
the length of the array. This is a trial feature, if it works out then 
these will happen in sequential releases:

1. length will become deprecated inside [].
2. length will be removed as the implicitly declared length, and it will 
be just another identifier.
-----------
Exactly five years later, step 1 was implemented, but only for D2:
-----------
Version D 2.041 Mar 7, 2010
New/Changed Features

Use of length inside of [ ] is now deprecated, use $ instead
-----------
We're still waiting for step 2.