Any drawbacks to Nil[A]?

Language Design
12

In 2.12.4 and 2.13.0-M2, they do conflict in several ways. Given

trait MmmList[+A] {
  def apply(i: Int): A
}

object MmmNil extends MmmList[Nothing] {
  override def apply(i: Int) = ???
  def apply[A]: MmmList[A] = this
}

object Tests {
  def app[A](f: Int => A): A = f(0)

  def supposing[Q](someList: MmmList[Nothing], q: Q)(implicit fromQ: Q => Int) = {
    // doesn't eta-expand with the general form
    val before1 = someList.apply _
    val after1 = MmmNil.apply _
    // ...even if you say which arity you want
    val before2 = someList.apply(_)
    val after2 = MmmNil.apply(_)
    // doesn't eta-expand *in an expected-lambda context*
    val before3 = app(someList.apply)
    val after3 = app(MmmNil.apply)
    // ...even if you say which arity you want. I'm surprised; I thought
    // this would work.
    val before4 = app(someList.apply(_))
    val after4 = app(MmmNil.apply(_))
    // suppresses implicit conversion, which now comes too late
    val before5 = someList(q)
    val after5 = MmmNil(q)
  }
}

All five after variants fail to compile, whereas their before brethren are just fine.

Some improvements to overloads are planned for 2.13 to make collection-strawman practical. As of 2.13.0-M2, however, all five above examples fail in exactly the same way as with 2.12.4. Since these failures are unrelated to the requirements of collection-strawman, there is no motivation to improve matters here.

Whether these conflicts matter is a different question.

This does not work, likely for the same reason adding curried Option#fold as a regular method broke Scalaz’s uncurried form.