Hi Eric, I agree that this proposal is really two proposals that are relatively orthogonal (defaults for other type classes, and defaults across modules). Worth splitting maybe? Following your recommendation, focusing on NamedDefaults first. Indeed, if he had the ability to write default IsString (T.Text) I might have voted OverloadedStrings into Haskell2021 :-) So definitely a valuable proposal, but I think we some questions are unanswered yet. For default A (Int,String,()) default B (String,(),Int) (A t, B t) => t it says “just don't do that;”. But doesn’t that imply that, if one wants to rule out all use-site conflicts, there must be a global priority ordering of types across all defaultable type classes where each individual default clause is a subsequence of? Would it then make sense to just statically forbid such “illegal” orderings, i.e. reject if two default declarations are in scope that could lead to that? Would that rule out declarations that we’d want to allow? And then there are the multi-parameter type classes… they are discussed in the end, but not part of the proposal. I kinda feel that instead of taking one small step here, we should aim a bit higher and find something that works not just for some type classes, but most of them out there. Or at least understand why that would not be possible/desirable. That said, I don’t consider myself an expert on type class defaulting, so happy to hear other’s opinions here. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/