Evolving the D Language

[Walter Bright]

As time moves on, the D language has to evolve as well. What do we do with 
obsolete and/or problem-causing, legacy features?

Our answer was deprecation. The deprecation starts out as just a message, which 
can be disabled, or can be set to be errors. The deprecations could last for 
many years, then become errors, but with a "-revert" switch if one still wanted 
to use them.

I thought that was a straightforward approach, giving people many years to 
modernize their code.

I was wrong. I heard you. We're going to have to change course.

We also failed with the `alias this` for classes deprecation, in that we did not 
offer a reasonable replacment.

We need a new approach to evolving the language (because evolve or die). I'm 
working on the following:

1. continue to evolve the language
2. not deprecate things unless we have to
3. keep legacy code running without complaint as long as we can
4. re-evaluate current deprecations with this in mind
5. resurrect selected legacy constructions that have been removed
6. better documentation for evolving legacy constructions

To that end, we have a new switch: -wo

Currently, the switch does nothing (!). But its intent is, when thrown, to give 
a warning about use of legacy constructions (adding -we will also make them 
errors). The idea is to simply not bother people building legacy projects with 
annoying messages, unless they are pro-actively asking for those messages. This 
way, people can modernize their code at their pace, not at our pace.

But what about constructions that we have learned are unsafe and shouldn't be 
used in @safe code? Code that uses unsafe constructions is not necessarily buggy 
code. It may be perfectly correct, it's just that the compiler cannot *prove* it 
is correct. This means the compiler will continue to accept @safe code with 
unsafe legacy constructs. If you need the compiler to do the more thorough @safe 
checking, -wo will have to be used, and you can scrub out the old constructs as 
you see fit.

Your thoughts and advice are appreciated. Feel free to add this thread your wish 
lists on legacy feature resurrection that should have priority. Or if you've got 
a better idea, let us know!

And yes, `alias this` for classes is going back in.