This has been discussed a while back on the scala-language mailing list.
Martin Odersky points out:
One problem with leaving out new
is that ambiguities arise for anonymous classes: Instead of
new Foo(x) { def y = x + x }
you'd get:
Foo(x) { def y = x + x }
The parser would reject this, because it thinks that the braces { ... } enclose a function argument,
so definitions would not be allowed.
I would also add that you'll have problems with parameter-less constructors. Like
class Foo
How would you instantiate this, especially if there was a companion object? Of course, one could have kept new
for these cases as an optional keyword.
A more theoretical reflection is that in class Foo
, Foo
is a type not a value. In general, you cannot call any methods on a type, such as synthetic apply()
or a hypothetical .new()
. For case classes apply
is defined on the companion object which is a value. Then adding a synthetic apply
to any class would imply that you always get a (synthetic) companion object for any class.
It would not have been impossible to do away with the new
. In the experimental Scala-Virtualized project you do have a virtual new
. For the same aesthetic question one could have done away with if
and while
etc.