[pents90]

As a long-time Java developer, I really hope they won't implement JEP 286. I think type inference by the compiler is a bad idea, as it results in less readable code, more bugs, and an unnecessary burden on the compiler. I think all the examples where type inference is convenient are trivial cases, but the downsides start to crop up in real-world, large code bases. So it's something that makes the easy things slightly easier and the hard the things harder.

Type inference already happens for you when you are using a good IDE, like IntelliJ IDEA. You can just use the "Introduce Variable" refactoring. And better yet, it self-documents your code with the variable's type.

[pwaivers]

> Less readable code

Maybe it is because we are used to our own paradigms, but the following is no less readable to me because of inference. And these are the 95% of cases.

  var index = 0;
  var name = "pwaivers";
  var names = new List<string>();
  var nameMap = new List<string, Dictionary<int, Address>>();

> more bugs

I have never seen a bug arise because of type inference. Do you have an example?

> unnecessary burden on the compiler

The compiler does a lot of work and this would probably be insignificant to add to it. However, I am totally open to learning more about this.

[kentosi]

The examples you've given have direct values. Try:

  var index = getIndexFromSomewhere();
  var name = getHandleFromUser("peter", "waivers")

The type isn't as clear anymore.

*Edit: I'm absolutely a fan of the var syntax, having dabbled with scala. I'm just expressing what I think the original author's complaint is.

[meandmycode]

Yea, I remember the same was said when C# was introducing var, it's a valid concern but in reality it really isn't

[saosebastiao]

I think you're suffering from Stockholm syndrome. I have never experienced a bug using scala's type inference that could have been prevented by more required boilerplate. Type inference is 100% benefit with zero drawback.

If you really want to know what a type is resolved to, you have both compilers and IDEs there to tell you. Relying on an IDE to write code is just hacking over a weak or broken language.

[tormeh]

To be fair, the compiler errors you get with inferenced types will often lead you to write in the types anyway, to ringfence the bugs. Type inference often gives you really messed up error messages when you've done a mistake.

[richard_todd]

It's not a compiler burden because it already has to determine the type of the right-hand side for typechecking purposes. So, the compiler actually does less work in the 'var' case, simply assigning the calculated type to the left-hand side rather than checking against a user-supplied type.

[tormeh]

Not really. Without type inference, there's always a pretty short path to the type: For "int x = y" you only have to check that the type of y is int. If you have type inference "int x = y" is a lot harder to validate, because y may have been defined like so "var y = z". So now you have to create some kind of list of variables and their types, start at the ones that are explicitly defined like "int a = b" or "c = 5" and then fill in the types of the rest as you find a reference to the ones you know.

[coldtea]

>As a long-time Java developer, I really hope they won't implement JEP 286. I think type inference by the compiler is a bad idea, as it results in less readable code, more bugs, and an unnecessary burden on the compiler.

It is already the case in lots of languages since 1990s and the sky has not fallen...

[pacala]

Intellij: View type info [on Mac: Ctrl + Shift + P]. Of any [sub]expression. Whenever you care about that level of detail. On-demand self-documented code.

[nonsince]

Rust, ML, Coq and Haskell have type inference and if those four are known for anything it's reliability and bug-free code.