6 ms·

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:

• namelezz 11y ago
  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.
  • msbarnett 11y ago
    > 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.
    • namelezz 11y ago
      > If anything it's more readable, since your code isn't littered with redundant type info. I fail to see the redundant type info. Example 1: int maxWeight = blocks.stream() .filter(b -> b.getColor() == BLUE) .mapToInt(Block::getWeight) .max(); "int" is not redundant type info here. Example 2: List<String> list = new ArrayList<>(); // (1) var list = new ArrayList<String>(); // (2) Many would say List<String> in (1) is redundant but I would argue otherwise. The intention of List<String> in (1) is to reference to the underline ArrayList through List interface. (1) is trying to encourage programming to an interface while (2) just completely destroys the practice by inferring the type for list variable to be ArrayList<String>. That means subsequent method invocations after (2) can be methods from ArrayList not List.
      • haffla 11y ago
        You fail to see that type inference is optional. So yes for readability's sake, in your first example I wouldn't omit the "int", but in simpler cases you CAN omit if you want. And that's just nice, end of story.
        • nikolay 11y ago
          Optional, alright, but promoting bad practices. If people like dumb-down languages, there are plenty of them already!
          • oldmanjay 11y ago
            What are the bad practices being promoted by this? How does it qualify as dumbed down? Simply ranting about things that, charitably, you don't seem to understand, does not make the rants valid.
            • nikolay 11y ago
              The best practice is that the type of the variable is of the interface, not the implementation except in some special cases.
              • wtetzner 11y ago
                So stop using constructors and start using static factory methods. The return type of a static factory method can be the interface type.
                • nikolay 11y ago
                  Yeah, let's UML the hell out of everything to be enterprisey and be Martin Fowler-approved! This is what turned off a lot of people before!
                  • wtetzner 11y ago
• kodablah 11y ago
  > Regarding val vs let I like the approach mentioned of just reusing final for immutability.
  • cballard 11y ago
    Making the immutable version the same length as (or preferably, shorter than, e.g. Rust) the mutable version encourages the use of immutability.
  • skippytheroo 11y ago
    val is a much better idea. Final is longer to type, in many cases as long as just declaring the type. We should be encouraging immutability not discouraging it by making it more verbose than necessary.
• arrty88 11y ago
  I've been doing List<String> list = new ArrayList<>(); Isn't that good enough?
  • hyperpape 11y ago
    No. The List<String> is almost as redundant as the RHS <String> was.
  • the_af 11y ago
    For your example, it makes no difference. However, take a look at the other example mentioned at the beginning: var stream = list.stream(); // infers Stream<String> How would you write it in order to take advantage of type inference?
• Others 11y ago
  As far as val vs let goes, I actually prefer val, because it has symmetry with var. That is to say "variable foo" is more similar to "value foo" than "let foo," since "value" is an adjective like "variable". Of course, I suppose this is personal preference.
• rat87 11y ago
  there is but I don't know if it can be retrofitted onto java. In rust and haskell, ect. types can be worked out backwards so that the type is figure out with use. fn main() { let mut v = Vec::new(); v.push("hello"); v.push("world!"); println!("output: {:?}", v.join(" ")); } the type of v is `Vec<&str>` worked out backwards from where &str literal is added(since the type of push is fn `push(&mut self, value: T)` the T generic of Vec<T> must be &str).