- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
primitive type alias expunging
Wed, 2009-11-18, 22:34
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.
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