A big problem with compiler switches is that they have to apply to everything in a build, or things won't line up. You can't pick and choose which module it applies to, even if you could, its going to lead to people having a very bad day.

This is another reason why strict by default is the right choice.

If you become strict instead you break peoples code. But if you allow obsolete you do not (it could appear anywhere in a build graph).

Either way, I don't think this is 100% there yet.

On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:
> 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.

There was no way to rewrite the code without breaking dependent code. That should not happen with a routine compiler release.

> We have the right to backtrack on bad ideas instead of keeping them forever.

Marking a feature as obsolete doesn't mean it has to be supported forever. Presumably at some point support will be dropped. Possibly obsolete features could become deprecations before they are actually removed.

> The current deprecation system is very good.

For something like alias this in classes, making it obsolete instead of deprecated signals that the feature won't be removed in 20 months (based on a 2-month release cycle, 10 release deprecation cycle as standard).

On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:
>
> To that end, we have a new switch: -wo

Isn't that just another "deprecation" switch?

I'm now thinking that deprecations in general are causing us headaches, but the all-or-nothing approach. You either turn all warnings/deprecations into errors (i.e. keeping your code clean, preventing people newly introducing deprecated/bad constructs), or none of them.
If there is a way to selectively enable/disable warnings/deprecations, then the problem goes away. Because if a newly introduced deprecation is causing trouble, you can selectively disable that one and continue development while being protected from introduction of old deprecations.

I added this in the past but it was slain :((
https://github.com/dlang/dmd/pull/5592

-Johan

On Friday, 7 July 2023 at 13:01:53 UTC, Nick Treleaven wrote:
>
> Possibly obsolete features could become deprecations before they are actually removed.

It just seems to me, instead of complaining when features become deprecated, people will complain when obsolete feature becomes deprecated and they see the message. The proposal here is that they see the message later. In the meantime, nothing will prevent people from using the obsolete feature all over.

On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote:
> 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.
> [snip]

The question is whether there is a migration path. If they removed functionality that didn't have a good foundation and put it on one with a better foundation, then I think people would have been ok (like removing Complex numbers was annoying, but std.complex exists or you can write your own).

The current approach had a lot going for it. I'm sympathetic to those who favor being strict by default, but I don't feel strongly as I'm not really sure what I think about Hipreme's comment about how this all interacts with dependencies. If the new switches could turn deprecation errors into warnings or hide depreciation errors/warnings, then that might be a good complement to the revert switch (revert with a version number is also an interesting idea).

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?
>
> [...]

Yes, I agree with all of this. Thank you.

On 7/7/2023 7:56 AM, Guillaume Piolat wrote:
> It just seems to me, instead of complaining when features become deprecated, people will complain when obsolete feature becomes deprecated and they see the message. The proposal here is that they see the message later. In the meantime, nothing will prevent people from using the obsolete feature all over.

The problem has a lot to do with people wanting to use 3rd party libraries, and it being impractical to upgrade those libraries when the maintainer of those libraries is no longer active. If a user's project depends on several such libraries, it places an undue burden on the user.

On 7/6/2023 8:14 PM, Richard (Rikki) Andrew Cattermole wrote:
> 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.

For reference:

https://github.com/dlang/dmd/pull/13773