https://issues.dlang.org/show_bug.cgi?id=14232

--- Comment #10 from Martin Nowak <code@dawg.eu> ---
(In reply to Ketmar Dark from comment #7)
Once dfix is ready for primetime and is release with dmd we might switch to a
model where we such changes are accompanied with a rewrite in dfix. But for
now, it's really unprofessional to suddenly break code.

--

https://issues.dlang.org/show_bug.cgi?id=14232

--- Comment #11 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
but why? it's not the compiler task to babysit old and broken code, it's lint(dfix) task. removing that burden from compiler allows alot more possibilities, as compiler code stays clean, and dfix can accumulate alot of checks, allowing easy fixing the code even from the very old compiler release with step-by-step upgrading.

i'm far from saying that nothing should be done. actually, i'm saying the exact opposite thing: it's time to bless dfix and bundle it with compiler package, so people can upgrade to new compiler versions without much pain.

--

https://issues.dlang.org/show_bug.cgi?id=14232

--- Comment #12 from Dicebot <public@dicebot.lv> ---
Can you please resist the temptation to start another pointless discussion with ketmar? I don't want to disable notifications for this issue.

--

https://issues.dlang.org/show_bug.cgi?id=14232

--- Comment #13 from Martin Nowak <code@dawg.eu> ---
Thanks @dicebot.
It's this error you're triggering.
https://github.com/9rnsr/dmd/commit/1b932b9282df6ed312b6da0031417ea0d4f8faa5#diff-62dcb5f0ffc3089b7565897d8beb3322R918

At best you pass a `bool onlyWarn = false` to `appendStorageClass`, and then pass `true` for places were it didn't previously error.

The actual error was introduced here. https://github.com/D-Programming-Language/dmd/pull/3689

Be careful to preserve existing errors. https://github.com/9rnsr/dmd/commit/1b932b9282df6ed312b6da0031417ea0d4f8faa5#diff-62dcb5f0ffc3089b7565897d8beb3322R503

--

https://issues.dlang.org/show_bug.cgi?id=14232

--- Comment #14 from Dicebot <public@dicebot.lv> ---
Thanks, working on it.

--

https://issues.dlang.org/show_bug.cgi?id=14232

--- Comment #15 from Martin Nowak <code@dawg.eu> ---
(In reply to Ketmar Dark from comment #11)
> i'm far from saying that nothing should be done. actually, i'm saying the exact opposite thing: it's time to bless dfix and bundle it with compiler package, so people can upgrade to new compiler versions without much pain.

Yes, just like I said. Once dfix is ready and we include it in our release we might modify the policy for such changes. But we include dfix just a few days before a release. How about you work with Brian on getting it integrated for 2.068?

--

https://issues.dlang.org/show_bug.cgi?id=14232

--- Comment #16 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
> How about you work with Brian on getting it integrated for 2.068?
i've never seen a call for help from him. but sure, if he needs any help i can provide, i'm ready to do that... after dfix inclusion will be officially approved by Walter and Andrei. working for a trashcan is not fun.

--

https://issues.dlang.org/show_bug.cgi?id=14232

--- Comment #17 from Kenji Hara <k.hara.pg@gmail.com> ---
(In reply to Martin Nowak from comment #4)
> (In reply to Ketmar Dark from comment #3)
> > should any bug be deprecated first — just in case somebody wrote invalid code relying on that bug?
> 
> Usually yes, but within reason, depending on how complicated it is to fix the code compared to how complicated the deprecation is.

An application of deprecation process will be legitimate only when the deprecated behavior was valid and designed feature in old versions.

Accepting redundant attributes had not been documented in language spec, it has been just accidentally accepted. Therefore, consistently disabling them all is a bugfix. Even though it will break some user code suddenly, deprecation process should not be applied.

And from a realistic reason, It's difficult. In old dmd version, some of redundancies were properly disallowed, and remaining were (unintentionally) accepted. To deprecate invalid accepted case, we should emulate old unintentional compiler behavior. It's too costly, and I don't want to do it.

--

https://issues.dlang.org/show_bug.cgi?id=14232

--- Comment #18 from Martin Nowak <code@dawg.eu> ---
(In reply to Kenji Hara from comment #17)
> Accepting redundant attributes had not been documented in language spec, it has been just accidentally accepted. Therefore, consistently disabling them all is a bugfix. Even though it will break some user code suddenly, deprecation process should not be applied.

No, we shouldn't just break code without good reason. Certain changes that detect latent bugs might be OK (escape analysis), but fixing this error hardly adds any benefit for code owners. It's very trivial to fix though.

There are plenty of small issues with dmd and if the compiler doesn't adhere to the specs we can't any programmer to do this instead.

> And from a realistic reason, It's difficult. In old dmd version, some of redundancies were properly disallowed, and remaining were (unintentionally) accepted. To deprecate invalid accepted case, we should emulate old unintentional compiler behavior. It's too costly, and I don't want to do it.

I understand that, that's why I initially close the report and it's what I meant with comment 4.

> Usually yes, but within reason, depending on how complicated it is to fix the code compared to how complicated the deprecation is.

But I'm fine with Dicebot adding a deprecation, if he want's to do it.

--

https://issues.dlang.org/show_bug.cgi?id=14232

--- Comment #19 from Dicebot <public@dicebot.lv> ---
https://github.com/D-Programming-Language/dmd/pull/4458

--