A few general thoughts

Jonathan M Davis jmdavisProg at gmx.com
Fri Apr 29 10:37:04 PDT 2011


> This post is in fact mainly about removing delete, but I didn't wont make
> everyone angry just with title.:) I am sure not expert to language design,
> so I should probably be quiet, but I have question.
> My question is: Didn't break it (i.e. removing delete) compatibility?
> 
> In my opinion every decision have both bad and good sides, which should be
> carefully weighted. (I hope that you can understand me, because english is
> not my native language)
> 
> For me, backward compatibility is important issue. I am sure that this
> topic was discussed here many times, but I want just say that I vote for
> more careful way to make changes in language. It is even more important
> for young language, I believe, because many libraries and tools can stay
> incompatible for long time. For example I am not using D2.0, because I
> have incompatible libraries in my project and it seems it cannot be fixed
> easy way.
> What about mark features to remove as "deprecated" and write warning by
> compiler, if they are used? So feature would be really removed after some
> time in next version, and people would be informed this way and have time
> to prepare your code or discuss change.
> 
> I am not against breaking compatibility entirely, but it should be
> compensated with really significant improvement.

The decision on removing delete was made some time ago. It just hasn't been 
done yet. The same goes for a few other features such as scoped classes. 
However, aside from already planned changes, there shouldn't be many breaking 
changes to the language in the near future. D2 is supposed to be finalized 
enough with the release of TDPL, that breaking changes should be fairly rare. 
There are still things that need to be sorted out and some breaking changes 
may be necessary, but it shouldn't be all that common.

The general philosophy on breaking changes at this point though is to do it in 
stages. First, the compiler will complain at you. Following that, the item 
will be deprecated, and you'll have to compile with the -d flag or your code 
won't compile. Finally, the item will be removed completely, and any code 
which still uses it will break. I'm not sure that _all_ breaking changes will 
be able to have that smooth a transition, but that's the goal.

- Jonathan M Davis


More information about the Digitalmars-d mailing list