case class optimisation

[fommil]

it is quite common when writing invariant ADTs that have an "empty" element to use something along the lines of the following encoding

sealed abstract class Maybe[A]
final case class Empty[A]() extends Maybe[A]
final case class Just[A](a: A) extends Maybe[A]

but this incurs an object allocation overhead that must be mitigated with the following (ugly) pattern

  final case object Empty extends Maybe[Nothing] {
    def apply[A](): Maybe[A] = this.asInstanceOf[Maybe[A]]
    def unapply[A](e: Maybe[A]): Boolean = this == e
  }

it would be fantastic if the compiler automatically added the apply() and unapply() under these circumstances.

[sjrd]

Under what circumstances?

What code do you expect to write, exactly, and what do you expect would be generated?

[fommil]

The ticket has the expected input and output, what am I missing?

[fommil]

Damn, we found that this optimisation breaks exhaustivity, see scalaz/scalaz#1579 (comment)

[jvican]

I think @sjrd is looking for a more formalized version of the codegen (?). I agree this would be useful, I’ve seen this pattern in many places - it’s quite common when you define tree-like data structures and it’s not clear for beginners what they should do to have a singleton empty.

[sjrd]

The ticket has the expected input and output, what am I missing?

Then it's not sound in general:

final case class Empty[A]() extends Maybe[A] {
  var oops: A = _
}

val e1 = Empty[Int]()
e1.oops = 5
val e2 = Empty[String]()
e2.oops = "foo"
println(e1.oops) // prints "foo"
val s = e1.oops // throws ClassCastException
println(s)

And anyway, people could rely on the identity of the Empty()'s.

[fommil]

We may be willing to accept the loss of exhaustiveness checking in scalaz, which might make this a reasonable optimisation still to make.

I feel like there should be some form of epic to capture optimisations that can be made when code is pure. Your var breaks that.

I feel like I could code this up, but I don't understand what you're asking in terms of a formal spec... so anybody who feels they know how to write formal specs can comment here. I shan't be adding one.

[fommil]

the pattern is flawed.