Guillaume Martres

From past experience, I can tell you that one of the most difficult part of compiling the collections in the standard library is proper support for F-bounded polymorphism, there are...

> Terms with inferred types are already ruled out from appearing in paths (e.g. x.type is not allowed). In your blog post you mentioned that no Scala language feature prevents...

> I'm pretty sure Scala users would be willing to give up on inferred types connivence in some cases (in paths and in imports) if they were promised 10x compiler...

I know how main methods work, I was more wondering about what would need to be adapted in the code :). In particular I see that you're doing a bunch...

> I see there is a PR open now to bring 0.29 support to scalatest 3.1.x which I seemingly prematurely assumed to be EOL. FWIW, it looks like scalatest 3.1...

PR for the scalacheck migration: https://github.com/fthomas/scala-steward/pull/853

I didn't change it, it's exp:novice

Instead of adding every new Scala 3 type (and tree) to the semanticdb spec bit by bit, could semanticdb switch to reusing the type and tree representation from TASTY? This...

You could reuse the tasty format for trees/types common to all languages, and add extra ones for the stuff specific to other languages. Right now, the Scala 3 compiler contains...

> or enabling semanticdb to embed tasty somehow? Something like that yeah, I don't actually know why exactly semanticdb needs to able to refer to TypeLambda and such, but assuming...