...

My suggestion is to split this module into two, and stop the implicit import/export of the incomplete instances from Data.Generics. I don't think that this is a good idea.

Could you please elaborate on your reasons?

...

Pro: - the instances are still available, and only one explicit import away, so 'deriving instance Data' for types containing uninteresting functions is still convenient But suppose you want to make such an instance in a library you write. Then you will import the instance, which means that it will be visible to all users of your library too, so they cannot define their own instance. Nor can they use other libraries that define their own instance.

True. But the current situation is even worse: we either get all instances (good and bad) or none, and to get none, we'd have to jump through hoops (not using Data.Generics, but importing its component modules directly; and anyone trying to mix such code with code importing Data.Generics is going to be in trouble). There might well be a better way of making deriving happy, without such nasty side effects, but it will have to start with not having those faulty instances by default.

I believe instances really do have to be global.

Instances are global. The only control we have are over the class we define instances of and the type we define instances for. The instances in question are of a non-local class, for non-local types, so if they are implicitly imported, we're stuck with them. The instances I don't want to be stuck with turn compile-time errors into runtime errors for some methods, and violate nice invariants for other methods. Claus