> Now if you want to change getFoo to return a Foo2, and doSomethingWithFoo to take a Foo2, you have to go change every place where these two functions are call

> Now if you want to change getFoo to return a Foo2, and doSomethingWithFoo to take a Foo2, you have to go change every place where these two functions are called and update the explicitly declared variable type. This is wrong, and mixes up what side effects actually exist, and what questions you can ask the compiler. getFoo is going to construct an object with some type that type must be assignable to its return type, and then that return type must be assignable to your declared variable type. declaring the type of your variable isn't just copying the type from the return signature, its a query to compiler about assignability (which is a query about ordering on the subclass relation). You could imagine changing the type of the object, but not the return type of the function, or the return type of the function, but not the type declaration of the variable. if you declared your variable to have a type and then try to assign that variable to the parameter (as the argument) of doSomething, you are again asking the compiler is my variable assignable to the parameter of this method. if you are just "composing" 2 functions, then sure you might think of type declarations as boilerplate. but if you think of variable assignments as queries to the compiler then you gain something by declaring types. This doesn't even get into the ideas of variance and contravariance of the subclass relation over function types as well.