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

primitive type alias expunging

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

I have managed to removed the primitive type aliases from Predef
(deprecated since 2.6.0 at least) and have everything working again.
Not a task I'd recommend for the thrills.

Question before I commit anything. Spec 8.2 says:

A type variable pattern is a simple identifier which starts with a lower
case letter. However, the predefined primitive type aliases unit,
boolean, byte, short, char, int, long, float, and double are not
classified as type variable patterns.

...That language should probably be changed one way or another because
it refers to those aliases as if they are a supported part of the
language rather than the long deprecated historical artifacts they are.
But the question is, should they continue to be reserved words in a
pattern matching context? I don't see any good reason they should, and
that'd be the easiest spec change ("delete sentence") but this will
represents both a spec and behavioral change so I figured it was outside
the scope of the deprecation janitor.

Also, there are three other lower case identifiers which aren't variable
patterns which are not mentioned there: true, false, and null.

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: primitive type alias expunging

On Wed, Nov 18, 2009 at 10:28 PM, Paul Phillips wrote:
> I have managed to removed the primitive type aliases from Predef
> (deprecated since 2.6.0 at least) and have everything working again.
> Not a task I'd recommend for the thrills.
>
> Question before I commit anything.  Spec 8.2 says:
>
> A type variable pattern is a simple identifier which starts with a lower
> case letter. However, the predefined primitive type aliases unit,
> boolean, byte, short, char, int, long, float, and double are not
> classified as type variable patterns.
>
> ...That language should probably be changed one way or another because
> it refers to those aliases as if they are a supported part of the
> language rather than the long deprecated historical artifacts they are.
> But the question is, should they continue to be reserved words in a
> pattern matching context? I don't see any good reason they should, and
> that'd be the easiest spec change ("delete sentence") but this will
> represents both a spec and behavioral change so I figured it was outside
> the scope of the deprecation janitor.
>
No, all of that can go. Rejoice! -- Martin

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