[blauditore]

> It also makes writing and refactoring faster (don't have to think about the return types, just the code flow).

I see what you mean, but isn't this one of the advantages of explicitly declaring types? If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change.

Also, I think remembering that autocompletion in VS had some trouble with correct type inference in some cases. But it's been a couple of years, maybe things are different now.

[mattmanser]

If you change the return type of a method without using var you would still have the exact same problems. That's not an actual problem.

I've used var since it came out years ago and never had this autocompletion problem you talk about.

You sometimes had to explicitly declare a type in foreach loops, but that had more to do with shitty legacy APIs that used abstract classes as return types. Wasn't really var's fault though.

[blauditore]

Consider the following scenario:

You have a Toilet object with a method flush.

  var toilet = house.getToilet();
  toilet.flush();

Now you find out that updating Toilet objects is somehow expensive and decide to wrap it into a Cache<Toilet>. Unfortunately, Cache also has a flush method, so there will be no compile time error, but functionality is broken now.

I agree this problem would also occur when using chained calls (house.getToiled().flush()), but explicit types could cover at least some of the cases.

[naasking]

> Now you find out that updating Toilet objects is somehow expensive and decide to wrap it into a Cache<Toilet>. Unfortunately, Cache also has a flush method, so there will be no compile time error, but functionality is broken now.

This has happened to me exactly 0 times since type inference was introduced in 2007/2008.

[msbarnett]

> If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change.

If you can refactor your code such that you change the return type of a method such that it returns an object of a different type, which nonetheless implements all of the methods used by clients of your type that accept and return types which in turn accept and return types that line up with the expectations of their clients, etc, etc, without having to look at or touch any of those clients, and end up with something that happily compiles but gives an unexpected result, you need to have a long and hard look at how you're using the language's type system, and why it isn't encoding your assumptions in a sane way.

Your code shouldn't be compatible with a different type unless it makes sense for your code to be compatible with that type. That's what the type system is for.

[blauditore]

One single common method is enough if that's the only one used in said context.

Sure, different types shouldn't use the same method name for different functionality, but it happens. And when such a scenario happens, I imagine it will be quite nasty to debug.