Re: Missing definitions of associated types

You make a good point about people who use overlapping instances deserving whatever they get (I'd personally love to see that whole mess removed and replaced with something less intrusive). The bit that most severely breaks my intuition here is that under normal, well-behaved circumstances, every instance of a class with associated data has its own distinct associated type(s). That is, there is a one-to-many relationship between instances and types. When a definition is missing, that breaks, and the relationship may become many-to-many. I suppose we may need to settle for this as long as overlapping instances in their present form are around. On Feb 18, 2016 12:49 PM, "Reid Barton" wrote:

Well, I see your point; but you also can't define a

On Thu, Feb 18, 2016 at 12:00 PM, David Feuer wrote:

...

It seems to be that a missing associated type definition should be an error, by default, rather than a warning. The current behavior under those circumstances strikes me as very strange, particularly for data families and particularly in the presence of overlapping.

...

This compiles with just a warning because Assoc Char *falls through* to the general case. WAT? This breaks all my intuition about what associated types are supposed to be about.

Well, I see your point; but you also can't give a definition for Assoc Char in the Foo Char instance, because open data family instances are not allowed to overlap. So if failing to give a definition for an associated data family is an error, then it's impossible to use overlapping instances with classes that have associated data families. Is that your intention?

I don't have a strong opinion here. I'm mildly inclined to say that people using overlapping instances have already signed themselves up for weird things happening, and we may as well let them do whatever other weird things they want.

Regards, Reid Barton