[ghc-steering-committee] #409: Exportable named defaults, Recommendation: Partial Accept

[Eric Seidel]

On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote:
> a different way to phrase that question might be: Do we want these
> defaulting declarations to behave just exactly like named things, or
> exactly like typeclass instances, or do we afford a new class with it’s
> own exporting/importing behavior. Is that a fair assessment?

Not entirely, I think. 

We currently have two types of import/export behavior:
named things, and typeclass instances. The proposal as currently
written places defaulting rules somewhere in between: defaulting
rules are exported like named things, but imported like class instances.
This is new, but not too foreign, as the behavior on both sides exactly
matches existing behavior we're familiar with. It's just the combination
that's new.

Some people have expressed concerns about implicitly importing
defaulting rules like instances, which led to my current recommendation
that we treat them *exactly* like named things on both sides. I think
importing defaulting rules like named things is unlikely to cause problems
in practice, so this seems like a good compromise.

Richard further suggested that defaulting rules should have to be explicitly
mentioned in an import list to be imported, which is a new import behavior
for which we have no existing intuition to guide us. In fact, our existing
intuition around import lists would actively mislead us here.

So the question is not just do we adopt existing behavior or do something
new. There are three options that have been proposed.

1. Adopt existing behavior exactly.
2. Combine existing behaviors in a novel way.
3. Introduce an entirely new behavior.

In general, I would say that as you move from (1) to (3), you need an
increasingly strong justification. I don't think I can justify (3) in this case
based on Richard's concerns about module changes impacting type
inference in downstream modules.

Does that make sense?