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.
