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.

I suspect that we kinda have it a little backwards.

Keep it strict by default, but allow more code to pass if desired.

This is how a build manager like dub should operate.

Part of the goal here is to make sure people don't go round using undesirable features by accident.

Also we should probably have the ability to turn on only a subset of the features based upon version. That way you can only accidentally add behavior that you already know about and not have infinite possibilities going forward.



And for the record I still want hex strings to come back. They were incredibly useful with no good alternatives when we talk about large tables of data being described.

On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:
> As time moves on, the D language has to evolve as well. What do we do with obsolete and/or problem-causing, legacy features?
>
> [...]

I respectfully disagree, and prefer to keep going on with the current deprecation and cleanup policy: Scott Meyers' DConf 2014 keynote all the way down.

On the other side, there's no problem at all in resurrect dead features, when living without them proved to be a pain (I agree with Rikki, hex strings).

/Paolo

On Friday, 7 July 2023 at 09:35:14 UTC, Paolo Invernizzi wrote:
>
> I respectfully disagree, and prefer to keep going on with the current deprecation and cleanup policy: Scott Meyers' DConf 2014 keynote all the way down.

+1

I've always agreed with the deprecation in the end, even complex numbers.
alias this was a relatively bad idea, even if an iconic feature.
I don't remember people from outside the community being impressed by alias this.
We have the right to backtrack on bad ideas instead of keeping them forever.
The __traits changed feature was aout fixing an incorrect behaviour. It took 10 min to fix.
The current deprecation system is very good.

On Friday, 7 July 2023 at 03:14:38 UTC, Richard (Rikki) Andrew Cattermole wrote:
> I suspect that we kinda have it a little backwards.
>
> Keep it strict by default, but allow more code to pass if desired.
>
> This is how a build manager like dub should operate.
>
> Part of the goal here is to make sure people don't go round using undesirable features by accident.
>
> Also we should probably have the ability to turn on only a subset of the features based upon version. That way you can only accidentally add behavior that you already know about and not have infinite possibilities going forward.
>
>
>
> And for the record I still want hex strings to come back. They were incredibly useful with no good alternatives when we talk about large tables of data being described.

There is 2 views to that side:

1: People doing their project and maintaining only their project.
2: People doing their project that has dub dependencies.


The problem right now, from my POV, is that people such as Grim is using dub dependencies. What that generates is that by the default functionality being showing the deprecation messages is that we need to modify unmaintained 3rd party code. How we use 3rd party code right now? DUB. The problem is that dub doesn't have a flag for keeping 3rd party code shut. So, in MY VIEW, dub should be the one to address that problem, not the D compiler itself.

One can see here that mostly people that disagreed with Walter's proposal is people which maintain all their own code. But that is obvious, since we're actively maintaining all of our dependencies basically. But thinking on a new user, what happens when they don't want to deal with 3rd party code or things feel like just out of control? It is not everyone that wants to fork something and use the forked version and start maintaining it.


On the `alias this` functionality, I think Walter is correct into saying that "we were wrong into deprecate this functionality without giving something to replace". `Alias this` is not incredible, but we have no reason to simply remove from the language without any kind of replacement.


But this is a long standing problem with dub that should be fixed: How global flags will behave or even having them: modifying `DFLAGS` environment variable is a hassle since it involves one command more, and most of the time it is not easily portable. Hipreme Engine has solved that problem by having something that runs before everything (and controls) , but dub itself hasn't solved. A good example of flags is the link-defaultlib-shared, -boundscheck and other things that changes how the language works somehow.

Warnings and deprecations aren't that different, so, I think dub should have a better way to manage 3rd party code. Also, seeing a lot of deprecation warnings as default for beginners is quite bad since they will be more discouraged to use its library and then someone will reinvent the wheel not because they're willing to do it for study, but because they will feel that it's NECESSARY.