On D development

[Jens Mueller]

Robert Klotzner wrote:
> Simply don't release a new stable version with new features, semantics,
> but first release an experimental version. Encourage people to compile
> their code with it, try out the new features/semantics, ... but always
> let them keep in mind, that things can break with further improvements.
> The idea is that features in an experimental release can be changed at
> any time without having to worry about breaking users code, because they
> expect it. It seems to me that until now things are just discussed very
> thoroughly, implemented and released. If this is really the case, then I
> guess the only reason this works so surprisingly well is because the
> people (Andrei, Walter, ...) are amazingly smart and have learned from
> the mistakes of other languages. But introducing a (limited) way of
> learning from own mistakes without breaking things, might be useful
> especially for new concepts not found in other languages.
> 
> I don't see how this complicates the compiler?
> 
> People could choose between using the experimental version for the
> awesome feature xy and taking the risk of fixing code with incompatible
> changes or stick with the stable version.

But this complicates the development of the compiler. There may be even
incompatible features. What do you do then?
Just because you release an experimental version of the compiler does
not ease integration of experimental features. Further at some point you
have to integrate a feature into the stable line.
I believe this is possible using a particular git work flow but I think
it's far from easy. Further there needs to be some API between parts of
the compiler. Maybe one can learn from the development of the Linux
kernel.
I'd like to have this but it's not as straightforward as it seems.

Jens