Breaking D2 language/spec changes with D1 being discontinued in a month

Dejan Lekic dejan.lekic at gmail.com
Wed Nov 28 00:51:01 PST 2012


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! :)



More information about the Digitalmars-d mailing list