A little of coordination for Rosettacode

[bearophile]

Brad Roberts:

> Requiring that users of the code in resottacode be using 
> bleeding edge, unreleased, compilers is a disservice to those 
> users.  Typical users will not and should not need to use 
> anything other than a released compiler.

Some of the rosettacode usages/purposes are:
- Trying new compiler features to see if they work correctly;
- Try the new compiler features to learn to use them effectively;
- To test the compiler betas to see if they have "regressions" if 
you try to use the new features.
- To show "good" (== short, fast, elegant, clean) D code, thanks 
to some nicer recently introduced compiler improvements;

So do you want to throw away those purposes?
Also keep in mind that if you throw away those purposes, I will 
lose some of my desire to work on Rosettacode, so you will have a 
less good and less updated rosettacode site. And I have found 
probably more than 300 dmd bugs/regressions thanks to those 
beta-related purposes. If you throw away those purposes you will 
lose a significant amount of my future bug reports. Are those 
prices low enough for you?


> The point is you shouldn't have to, unless the code is taking 
> advantage of broken behavior.  Any changes that 'have' to be 
> made due to a compiler release need to be carefully examined as 
> probable regressions in the compiler.

One of the points of improving a compiler is offering new 
features that are advantageous to use. If you don't want to use 
them it often means they are a failure. In many other cases the 
dmd compiler rejects older code that was wrong, because it 
becomes more tight.

Rosettacode tasks are usually short. If you don't try new 
compiler features in such little programs that have no 
production-level significance, then you will never try them in 
production code, and you will probably use just C-like code.

Being a little compiler-bold in those tasks is acceptable.

Bye,
bearophile