Final by default?

[Xavier Bigand]

Le 13/03/2014 02:13, Walter Bright a écrit :
> On 3/12/2014 5:40 PM, Vladimir Panteleev wrote:
>> Doesn't this sort of seal the language's fate in the long run, though?
>> Eventually, new programming languages will appear which will learn
>> from D's
>> mistakes, and no new projects will be written in D.
>>
>> Wasn't it here that I heard that a language which doesn't evolve is a
>> dead
>> language?
>>
>>  From looking at the atmosphere in this newsgroup, at least to me it
>> appears
>> obvious that there are, in fact, D users who would be glad to have
>> their D code
>> broken if it means that it will end up being written in a better
>> programming
>> language. (I'm one of them, for the record; I regularly break my own
>> code anyway
>> when refactoring my library.) Although I'm not advocating forking off
>> a D3 here
>> and now, the list of things we wish we could fix is only going to grow.
>
> There are costs and benefits:
>
> Benefits:
>
> 1. attracting new people with better features
>
> Costs:
>
> 2. losing existing users by breaking their code, losing new people
> because of a reputation for instability
>
> There aren't clearcut answers. It's a judgement call. The
> final-by-default has very large breakage costs, and its improvement is
> minor and achievable by other means.


IMO the major issue with changes is that they are propagated on new 
versions of dmd with other fixes. Why compiler fixes aren't back-ported 
on some old dmd versions? This will let opportunity to get fixes without 
breaking changes when a D users is to close of making a release.
I know it's a lot additional work for the D community but it will offer 
more choices.

On other idea is to create a major revision of D each year (maybe close 
after dconf) and present the previous one as the stable. The stable will 
receive all fixes and non-breaking changes.
This rhythm of one version per year will decrease in the time due to a 
lower necessity to make breaking changes.
Doing things like that will allow companies to migrate to the next 
stable D version progressively (with version checks).
We did something similar at my job with Qt, because we start with the 
version 4.8 and necessitas (unofficial android support). At the same 
time we had worked on 5.0 alpha integration (I did some bugs reports to 
help his development)