This page is no longer maintained — Please continue to the home page at www.scala-lang.org

the pattern matcher's 1503 sharp teeth

No replies
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.

It's sad the way I manage to keep replying to scala-internals@
no-such-machine. Trying again:

On Fri, Sep 25, 2009 at 07:08:52PM +0200, martin odersky wrote:
> As I explained already, I believe the check should really be made only
> when you bind a variable to a pattern. So
>
> case x @ pat => ...
>
> is to be interpreted as
>
> case x @ pat: =>
>
> That's a much more conservative change, which therefore is much safer.

OK, I have implemented this in r19170. I have the same reasonably
serious reservations I had when I first heard it. It may be a more
conservative change but it's less consistent and it's the kind of thing
which not knowing about will kill you. Here is the situation which
keeps me up at night.

object Test extends Application {
case class L() { def debugInfo = "Hi, I'm L." }
object N extends L() { override def debugInfo = "Hi, I'm N." }

def myBuggyFunction(x: L) = x match {
case N => println("It worked!")
case _ => println("It did not work.")
}

myBuggyFunction(L())
}

$ qscalac a.scala ; qscala Test
It worked!

// New Email from Management, Subject: "there's a bug, find it!"
//
// So we go back and change one line like so:
< case N => println("It worked!")
---
> case x @ N => println(x.debugInfo) ; println("It worked!")

// But instead of the anticipated debugging output...
//
$ qscalac b.scala ; qscala Test
It did not work.

--

To me this does not seem any more conservative, only a different choice
as to which expectations are most crushworthy.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland