I don't think adding {-# LANGUAGE Safe #-} (as we do with -Wall) is a good idea. The culprit is Safe-inference. While authors of the original Safe Haskell paper argue that it makes more modules Safe without package maintainer knowing about Safe Haskell, problems on Hackage have shown that it is not the case. We simply cannot rely on Safe-inferred modules (continue) being Safe when new versions are released, or worse, when their transitive dependencies change. There are various examples, I had made such mistakes ([1] is most recent one). ([5] is an example of "dependency" change, luckily caught by explicit pragmas). I have implemented -Winferred-safe-imports [2] to warn about such cases. And also -Wmissing-safe-haskell-mode [3], and used them successfully to cleanup some Safe Haskell mess in Edward Kmett's packages [4]. (If you rely on older versions of the listed packages to be Safe: don't, you are asking for troubles). Another alternative, which IIRC Edward used previously, is to just stamp {-# LANGUAGE Trustworthy #-} everywhere. But that undermines the whole idea in my opinion. It's almost as bad as saying nothing, every Trustworthy module have to be audited. Yet, you have to use Trustworthy if your package uses Data.Coerce or depends on vector-package or... So while I and others put many hours into making more of ecosystem Safe Haskell, I feel it is work with very bad ROI. (I wouldn't have done scan like [4] if there weren't also another reason to do it). So while people may freely discuss whether Safe-Haskell or sandboxes are better setup for running untrusted code, Safe Haskell have been around for almost a decade. If lambdabot is really the only application people can publicly talk about, I just don't feel it's good enough motivation to keep the language feature and add extra burden for the package maintainers. It is one more thing to know about, as if Haskell package authoring and maintenance weren't complicated enough already. As I mentioned, Safe-inferred just doesn't work in practice, so package maintainers have to be aware of it. (Compare to the good practice of having type signatures for top-level bindings, Safety is a part of module signature). TL;DR Safe Haskell requires buy-in from every maintainer, but there are barely any users. For how much longer we need to run this "academic experiment"? - Oleg [1]: https://github.com/ekmett/free/pull/204 [2]: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/safe_has... [3]: https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/safe_has... [4]: https://github.com/ekmett/lens/issues/959 [5]: https://github.com/haskell/time/compare/1.11.1...1.11.1.1 On 28.4.2021 17.16, Ignat Insarov wrote:
Maybe the problem is really that Safe Haskell is not taken to be a default good practice?
For example, it is easy to know that I should be setting `-Wall`, but hard to know that I should also enable some other warnings not included in `-Wall`. I know the latter because I read some blog posts somewhere and figured there is a consensus that these additional warnings are good, so I enable them by default.
For Safe Haskell, I have not read any such blog posts and I have no idea whether it is a good practice to enable it. This feature is not discoverable. This may be a marketing problem.
I have a template for my Haskell projects that enables a bunch of extra warnings, language extensions that I like to have enabled by default, dependencies that I wish were in `base`, and so on. Should Safe Haskell go into that template? _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.