Why is the declaration of type important in a statically typed language?

Question

I'm trying to understand the benefit of a programming language being statically typed, and through that, I'm wondering why we need to include type in declaration? Does it serve any purpose rather than to make type explicit? If this is the case, I don't see the point. I understand that static typing allows for type checking at compile-time, but if we leave out the explicit type declaration, can't Java still infer type during compile-time?

For example, let's say we have in Java:

myClass test = new myClass();

Isn't the type declaration unnecessary here? If I'm not mistaken, this is static binding, and Java should know test is of type myClass without explicit declaration of type even at compile-time.

Response to possible duplicate: this is not a question regarding static vs. dynamic type, but rather about type inference in statically typed languages, as explained in the accepted answer.

Mickiemickle

what if you have class B extends A, and A a = new B()? How should the compiler infer the type of a? – Communism

@femtoRgon This question is about type inference in statically typed languages, about dynamically typed languages. – Diplomatist

Sorry, *not about dynamically typed languages. :) – Diplomatist

Answer 1

There are statically typed languages that allow you to omit the type declaration. This is called type inference. The downsides are that it's tougher to design (for the language designers), tougher to implement (for the compiler writers), and can be tougher to understand when something goes wrong (for programmers). The problem with the last one of those is that if many (or all) of your types are inferred, the compiler can't really tell you much more than "the types aren't all consistent" — often via a cryptic message.

In a trivial case like the one you cite, yes, it's easy. But as you get farther from the trivial case, the system quickly grows in complexity.

Java does actually do a bit of type inference, in very limited forms. For instance, in this snippet:

List<String> emptyStrings = Collections.emptyList();

... the compiler has inferred that the method call emptyList returns a List<String>, and not just a List<T> where the type T is unspecified. The non-inferred version of that line (which is also valid Java) is:

List<String> emptyStrings = Collections.<String> emptyList();

Diplomatist

This is exactly what I was wondering, thank you!! So now I have another similar question: does the declared type allocate a different amount of memory in a language like Java? Like A a; vs B b;, if A has 100 instance variables and B has 0, let's say, would it make any difference during declaration, or does this come just at instantiation? How about for primitives? – Mickiemickle

@Mickiemickle It makes no difference at all; the memory is determined purely by the object, not by the reference to it. The reference is just a fixed size, so the three references String a, List<String> b and ArrayList<HashMap<String, String>> c will all take up exactly the same space (and actually, the JVM won't even know that they're anything other than "a reference to some object"). Primitives don't have polymorphism at all, but they do have different sizes (a byte is just one byte, a short is two bytes, etc). – Diplomatist

that's great, thanks! so in essence, the explicit declaring of type in a statically typed language like Java serves only to avoid type inference and has nothing to do with memory allocation? – Mickiemickle

Answer 2

It is necessary. You can have inheritance, where types are necessary.

For example:

Building build1 = new House();
Building build2 = new SkyScraper();

It is the same in polymorphism.

You can then collect all Buildings to array for example. If there will be one House and one SkyScraper you can't do this.

Soccer

Right, I can see that. But if you wanted build1 just to be a house, like House build1 = new House();, shouldn't you be able to drop the first House and just write build1 = new House();? – Mickiemickle

Thank you. I think my question wasn't worded right, and had more to do with type inference, which is what is explained in the answer by @yshavit. – Mickiemickle