odersky

Yes, but that needs changes in the compiler, right? Small changes, to be sure, but still...

And the Tasty and semanticDb formats to allow an ErrorType tag. That should be it. Should not take more than an afternoon. The only question is how to treat erroneous...

> I thought that it would be better to put such erroneous tasty into separate directory from usual classes. Maybe with a separate extension. Yes, maybe. I don't really know...

> However, I am less clear about the part where the compiler itself figures out what changed, and does incremental compilation all on its own. If I understand correctly, does...

@jchyb I would suggest to go the best-effort route with explicit error tags. Advantages: - Least effort: the compiler already knows how to handle error types. So all we need...

I don't think Tasty reader or Tasty query would ever need to see Tasty with errors in them. So, technically, this is a Tasty+ format for exclusive consumption in IDEs.

What would a migration scenario look like exactly? Can we ensure that there is never a silent change in meaning?

@cvogt > If two separate compilation units both define (foo = "bar"), will both have their own trait Labelled$foo defined or will generation happen once in a global place (e.g....

@soc The original use case is indeed database tables. It complements tuples, does not subsume them. It also assumes that Tuples get some kind of HList structure.

@szeiger I weakened the language to admit other implementation schemes that would not rely on class generation. Classloaders are really a nuisance, it would be so nice to be able...