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

exhaustive pattern match

7 replies
Vladimir Kirichenko
Joined: 2009-02-19,
User offline. Last seen 42 years 45 weeks ago.

Hi, All

def f(x:Option[Int]) = x match {
case None => 0
case Some(x) => x
case null => -1
case _ => -999 //isn't this unreachable code?
}

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: exhaustive pattern match

hm...
case class NoItsNotUnreachable extends Option[Int]
?

Am 24.01.2011 21:25, schrieb Volodymyr Kyrychenko:
> Hi, All
>
> def f(x:Option[Int]) = x match {
> case None => 0
> case Some(x) => x
> case null => -1
> case _ => -999 //isn't this unreachable code?
> }
>

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: exhaustive pattern match

after actually trying that:
the scala compiler doesn't allow this because option is sealed, but
nothing keeps the java compiler from subclassing option. the last case
isn't reachable unless you resort to voodoo.

Am 24.01.2011 21:32, schrieb HamsterofDeath:
> hm...
> case class NoItsNotUnreachable extends Option[Int]
> ?
>
> Am 24.01.2011 21:25, schrieb Volodymyr Kyrychenko:
>> Hi, All
>>
>> def f(x:Option[Int]) = x match {
>> case None => 0
>> case Some(x) => x
>> case null => -1
>> case _ => -999 //isn't this unreachable code?
>> }
>>
>

Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: exhaustive pattern match
case class NoItsNotUnreachable extends Option[Int]<console>:5: error: illegal inheritance from sealed class Option

On Mon, Jan 24, 2011 at 3:32 PM, HamsterofDeath <h-star [at] gmx [dot] de> wrote:
hm...
case class NoItsNotUnreachable extends Option[Int]
?

Am 24.01.2011 21:25, schrieb Volodymyr Kyrychenko:
> Hi, All
>
> def f(x:Option[Int]) = x match {
>     case None => 0
>     case Some(x) => x
>     case null => -1
>     case _ => -999  //isn't this unreachable code?
> }
>




--
Jim Powers
Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: exhaustive pattern match

Well, actually...

There are many many examples where commas can be omitted entriely

foo(a b c) and foo(a,b,c) are both equally unambiguous.

In cases where the lack of commas would be ambiguous the compiler can
complain appropriately. So, to generalize the case about class
definitions

def bar(a:Int b:String c:Option[List[Int]]) should pose no difficulty
to the compiler
(nor should:
def bar(a : Int b : String c : Option[List[Int]])
but as you can see if you abuse things a bit too much is gets harder
for the human to read things ;-) )

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: exhaustive pattern match

On Mon, Jan 24, 2011 at 09:43:32PM +0100, HamsterofDeath wrote:
> after actually trying that: the scala compiler doesn't allow this
> because option is sealed, but nothing keeps the java compiler from
> subclassing option.

The what? That roll of the guess dice cannot be close: if there were no
exhaustiveness checking because "the java compiler might subclass it"
then sealed would never do anything. You can never know when the java
compiler is going to bust in and start subclassing on you.

In theory that case should be unreachable, but I'm not surprised it
doesn't work. In general exhaustiveness checking doesn't survive much
in the way of nesting. It's in line with all the other bugs.

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: exhaustive pattern match
Never trust a java compiler with your code.  You never how low the classes will go.

On Mon, Jan 24, 2011 at 4:12 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
On Mon, Jan 24, 2011 at 09:43:32PM +0100, HamsterofDeath wrote:
> after actually trying that: the scala compiler doesn't allow this
> because option is sealed, but nothing keeps the java compiler from
> subclassing option.

The what? That roll of the guess dice cannot be close: if there were no
exhaustiveness checking because "the java compiler might subclass it"
then sealed would never do anything.  You can never know when the java
compiler is going to bust in and start subclassing on you.

In theory that case should be unreachable, but I'm not surprised it
doesn't work.  In general exhaustiveness checking doesn't survive much
in the way of nesting.  It's in line with all the other bugs.

--
Paul Phillips      | Appreciation is a wonderful thing; it makes what is
Stickler           | excellent in others belong to us as well.
Empiricist         |     -- Voltaire
ha! spill, pupil   |----------* http://www.improving.org/paulp/ *----------

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: exhaustive pattern match

On Mon, Jan 24, 2011 at 09:43:32PM +0100, HamsterofDeath wrote:
> after actually trying that: the scala compiler doesn't allow this
> because option is sealed, but nothing keeps the java compiler from
> subclassing option.

The what? That roll of the guess dice cannot be close: if there were no
exhaustiveness checking because "the java compiler might subclass it"
then sealed would never do anything. You can never know when the java
compiler is going to bust in and start subclassing on you.

In theory that case should be unreachable, but I'm not surprised it
doesn't work. In general exhaustiveness checking doesn't survive much
in the way of nesting. It's in line with all the other bugs.

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