Edward Kmett
You can wind up in perfectly legitimate situations where the name for the type you are working with isn't in scope, but where you can write a combinator that would infer to have that type. I'd hate to lose that.
It is admittedly of marginal utility at first glance, but there are some tricks that actually need it, and it can also arise if a type synonym expands to a type that isn't exported or brought into scope, so trying to push this line of reasoning too far I is possibly not too productive.
Good point. In particular, it's not weird at all want to export type synonyms on their own, particularly where ghost type parameters are used to select between only a few cases. Consider something like this (inspired by postgresql-orm): -- -- These are exported only by an internal module -- data NormalRef = NormalRef data UniqueRef = UniqueRef newtype GeneralizedRef refType targetType = DBRef Int64 -- -- These are exported by the module everyone imports -- type Ref = GeneralizedRef NormalRef type RefUnique = GeneralizedRef UniqueRef mkDBRef :: targetType -> Int64 -> GeneralizedRef refType targetType mkDBRef = const DBRef And now imagine somewhere in your code wanting to do something like the following. mkModelRef = mkDBRef (undefined :: MyModel) In fact, there may even be cases where the type is expressible with synonyms but GHC is unlikely to figure it out. (Or where multiple synonyms are possible and it isn't clear which would be best, so :t still prints the base type.) In short, I'd be sad to see the strict version of this rule put into place, particularly if it makes GHC stricter than Haskell2010 for code that doesn't rely on language extensions. David