| |
| Posted by Walter Bright | PermalinkReply |
|
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.
|