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.
