Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP 286: Local-Variable Type Inference

openjdk.java.net

Post reply on HN
Print view View original

11–20 of 132 posts

Re: JEP 286: Local-Variable Type Inference

#11

Post by arrty88 »

vivin wrote: post #6

This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way: var list = new ArrayList (); There is no way to infer the type of the generic parameter. So we will go back to doing: var list = new ArrayList (); Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond…

I've been doing List list = new ArrayList();

Isn't that good enough?

Re: JEP 286: Local-Variable Type Inference

#12

Post by linuxhansl »

Hmm... I agree it looks nicer.

Who's typing Java code all by hand these days, though? There various IDEs that save me all the typing.

It's also nice to be able to go the declaration of a variable to see exactly what type it is - that's mostly for code not written by myself, or old code that I do not remember. For local variable that's fine (I hope we won't infer types this way for method parameters), so I guess I like it there.

Re: JEP 286: Local-Variable Type Inference

#13

Post by msbarnett »

namelezz wrote: post #9
vivin wrote: post #6

This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way: var list = new ArrayList (); There is no way to infer the type of the generic parameter. So we will go back to doing: var list = new ArrayList (); Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond…

I hope this gets rejected. The given examples are too ideal as they are all using familiar Java standard APIs. I doubt if it's a good idea in practice since you can end up with unreadable code when integrating with third party APIs.

> I doubt if it's a good idea in practice since you can end up with unreadable code when integrating with third party APIs.

This works perfectly fine in practice as can be seen using comparable constructs in C#, C++, and many other mainstream languages.

If anything it's more readable, since your code isn't littered with redundant type info.

Re: JEP 286: Local-Variable Type Inference

#14

Post by cballard »

kodablah wrote: post #10
vivin wrote: post #6

This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way: var list = new ArrayList (); There is no way to infer the type of the generic parameter. So we will go back to doing: var list = new ArrayList (); Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond…

> Regarding val vs let I like the approach mentioned of just reusing final for immutability.

Making the immutable version the same length as (or preferably, shorter than, e.g. Rust) the mutable version encourages the use of immutability.

Re: JEP 286: Local-Variable Type Inference

#18

Post by breischl »

linuxhansl wrote: post #12

Hmm... I agree it looks nicer. Who's typing Java code all by hand these days, though? There various IDEs that save me all the typing. It's also nice to be able to go the declaration of a variable to see exactly what type it is - that's mostly for code not written by myself, or old code that I do not remember. For local variable that's fine (I hope we won't infer types this way for method parameters), so I guess I lik…

>>I hope we won't infer types this way for method parameters

No, it doesn't. From TFA: "This treatment would be restricted to local variables with initializers, indexes in the enhanced for-loop, and locals declared in a traditional for-loop; it would not be available for method formals, constructor formals, method return types, fields, catch formals, or any other kind of variable declaration."

Which is pretty much how C# does it.

I gather that it's common for functional languages to infer pretty much everything for you most of the time, which I think would actually be nice. But presumably that's either difficult or impossible in Java.

Re: JEP 286: Local-Variable Type Inference

#19

Post by mmatants »

I for one actually prefer to put a different type on the variable than the implementation. I.e. in the given case, I would actually use:

`List a = new ArrayList();`

I know that for some things it is convenient, but I appreciate the reminder to treat interface and implementation as distinct concepts.

Post reply on HN