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?