Surely those people's workflows are already broken by the fact that you can't evaluate much of anything without causing a panic.
If they are just loading the modules to check types and not actually running them, then they don't need `-fdefer-type-errors` in the first
#14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:20 elaforge]: place. So if someone's tool is thrown by an extra warning msg, they can probably just remove the flag. I also think it's reasonable to expect tools to be robust against unexpected messages at startup before the prompt comes. The use case for `-fdefer-type-errors` is so that you can run (and test) your module even when parts of it don't typecheck yet. E.g. suppose you write this: {{{#!hs module Pluralize where suffix :: Int -> String suffix 1 = "" suffix _ = "s" pluralize :: Int -> String -> String pluralize i s = s ++ i -- TODO }}} ...then you might want to load it into GHCi to play with the `suffix` function, or you may want to run unit tests on it, even though `pluralize` doesn't work yet (and doesn't typecheck). Deferring type errors is *especially* (some would argue *only*) useful in an interactive REPL: there isn't really a sharp workflow distinction between "compile time" and "runtime", so it is less important to produce type errors at compile time. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14963#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler