On D development

[Joseph Rushton Wakeling]

On 10/24/2012 09:38 AM, Robert wrote:
> When reading stuff, like: "Yes this is bad, but people use it already,
> so we could only possible change this in D3 or something" and reading
> endless discussions about a new feature (e.g. ref semantics) of how it
> could break things and so on, I thought it might be a good idea to
> implement new features in an experimental version, which can then be
> thoroughly tested and only if nothing bad found they will be merged in
> the stable branch. People simply have to be aware that they should not
> rely on semantics implemented in experimental.

The problem AFAICS is not _new_ features, or even stability per se -- the 
problem is modifying the behaviour of existing features, even if the 
modification is an improvement.

If you modify an existing feature, then it means that you will break downstream 
users' code -- not because your modification is wrong per se, but because that 
downstream code assumes that this feature will behave a certain way.  The larger 
your downstream codebase, the more problematic that becomes, hence the reason 
why certain kinds of change have to be limited to "major version" updates.

Also, it's not just a problem of causing work for downstream developers, but 
also about the sense of security/stability people have with D, that they are 
building on solid ground and not quicksand.  If people see features changing too 
often, they are likely to be unwilling to adopt D as a development platform.

D already has a deprecation path for features that really need to be changed, 
and where necessary this _does_ happen, but it's clear from past list 
discussions that this comes at a cost to D's reputation as a 
ready-for-production-use development language.

An experimental branch is a nice idea for other purposes, but it doesn't solve 
the problem you've identified.