On Wednesday, 28 November 2012 at 01:38:38 UTC, SiegeLord wrote:
Another DMD alpha, another set of previously valid code that no
longer compiles. With 2.060 it was the TypeInfo constness
changes in druntime, with 2.061 it is the dissalowance of
rebindability of the this pointer. The latter did make it into
the spec half a year ago, but recently it was actually
dissallowed in the beta. Unlike many other features of the sort
(e.g. octal literals) there is no warning or deprecation
errors... code that use to compile simply does not anymore.
In this last case, in principle, we were lucky... the spec was
changed. What about things like this:
http://dlang.org/attribute.html#inout . Are those undocumented
features liable to change at any time? What warning will there
be when somebody decides to submit an inout bug and somebody
else fixes it in a way that breaks existing code?
D1 is scheduled to be discontinued in a month, and every new
version of DMD keeps changing D2 in code breaking ways (or
worse, with backwards incompatible spec changes). I think that
unless people responsible for these things get their act
together and stabilize D2 against these issues, D1 support
should be extended until that happens.
Now you understand why I stick to Java at work, and use D only
for non mission-critical (small) projects. If I know that the
project is going to have large code-base I *do not* use D (by D I
always mean D2).
However, If I *had to* use D for a large-scale project I would do
the following:
1) Make my own fork of DMD, Druntime and Phobos, and maintain
them myself. Ie. merge only changes from the upstream that do not
break my own project.
2) Use these forked projects to build my project.
3) Periodically, when time permits, I "jump" to the latest
release of DMD, Druntime and Phobos. Naturally that would be a
big job, to fix my broken projects code. But as I said, I have
reserved a lot of time for this so I am fine with this.
This is how it is done in real world mostly. I know I did it in
the past. I used an experimental branch of a certain C++ GUI
toolkit in a large project. I did exactly what I explained above,
and it was all right! :)