[ghc-steering-committee] Please consider GHC Proposal #575 foracceptance.

[Eric Seidel]

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-instances/proposals/0000-deprecated-instances.rst#4examples

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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee