This mostly seems like an obvious win. Evolvability demands that any artifact that we produce support deprecations warnings. The one concern I have that is somewhat unique to deprecating instances is that users don't *explicitly* use an instance. There's an implicit chain of resolutions that leads to the use of a deprecated instance. Will that make it hard for users to understand *why* their program is bad, and *how* to fix it? It might just be brevity on Vlad's part, but I found it notable that the NFData example[1] just says "Don't use NFData (a -> b)." It gives no advice on what to do instead. With function deprecations it's usually easy to suggest replacements. I don't think this is a reason to reject the proposal, probably just something that library authors will need to be careful about when deprecating instances. [1]: https://github.com/int-index/ghc-proposals/blob/int-index/deprecated-instanc... On Fri, May 19, 2023, at 05:05, Moritz Angermann wrote:
Dear Steering Committee,
I strongly endorse GHC Proposal #575 https://github.com/ghc-proposals/ghc-proposals/pull/575, which suggests the introduction of deprecation pragmas on instances.
The proposal is a logical extension of Haskell's existing deprecation facilities. Its implementation would fill a notable gap in the language's current deprecation capabilities.
The lack of instance deprecation hinders controlled evolution of libraries and codebases, often leading to unexpected changes for users. By allowing instance deprecation, we can enhance the stability and predictability of Haskell codebases and improve the user experience.
In summary, Proposal #575 represents a valuable improvement for Haskell. I urge the committee to give it favorable consideration.
Best Regards, Moritz
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee