Bertram Felgenhauer via Haskell-Cafe wrote:
Unless the use case for which SafeHaskell was designed is common (and the replies here indicate that it's not), this is hard to justify.
The feedback here is not wholly representative. There's a reddit thread [1] where djdlc points out https://uniprocess.org/effects.html This is interesting because it demonstrates that the notion of safety can be *refined* from its use by the `base` library in the context of DSLs, because one can express which notion of safety applies through types, and confine the code that is ultimately executed through the type system. Obviously this will still break down when the type system is subverted as in https://gitlab.haskell.org/ghc/ghc/-/issues/9562 which Richard pointed out, or https://gitlab.haskell.org/ghc/ghc/-/issues/19287 which wz1000 demonstrated on IRC. But these are terrible bugs anyway; it's just that SafeHaskell boosts their implact from code that people shouldn't write to a potential security issue. Is anybody maintaining a list of these type system unsoundness issues? Apparently some people also enjoy the extra code discipline that producing Safe code requires (link by gentauro (=djdlc) on Freenode): http://blog.stermon.com/articles/2019/02/21/the-main-reason-i-use-safe-haske... Cheers, Bertram [1] https://reddit.com/r/haskell/comments/msa3oq/safe_haskell/ or https://teddit.net/r/haskell/comments/msa3oq/safe_haskell/