Guillaume Martres

I think that InlineConversion as a super-class could work yes. Playing a bit with the example in the SIP I think there's another missing language feature needed to make it...

> I think exhaustiveness is not checked when using custom unapply methods thinking You can mark a custom unapply as irrefutable by making its result type `Some[...]` instead of `Option[...]`:...

It helps in cases like this: ```scala scala> object A { def unapply(x: Int): Some[Int] = Some(x) } defined object A scala> object B { def unapply(x: Int): Option[Int] =...

Or add a static `List.of` (like https://docs.oracle.com/javase/9/docs/api/java/util/List.html#of-E...-) for the express purpose of Java interop ?

Also to clarify, dotty doesn't care about `empty` being there or not currently, but I'd love it if https://github.com/lampepfl/dotty/issues/2573 got solved in one way or another.

evil suggestion: make it `private[scala]` so that it's public from Java's POV but not Scala's :).

As a side-note, why do some collections have a package-private`emptyInstance` method ? https://github.com/scala/scala/blob/06392a55749f34ece097863c50a2af3fd6b3a88b/src/library/scala/collection/immutable/Set.scala#L131