10

Well, I really thought that this would work (inside a method):

var x, y = 1;

var x = 1, y = 2;

But it does not, it would not compile - "var is not allowed in a compound definition".

I guess the reason for this is an usual trade-off. This is not a very used feature and thus not implemented, but we could yes and may be might in a future release...

Jorn Vernee
  • 31,735
  • 4
  • 76
  • 93
Eugene
  • 117,005
  • 15
  • 201
  • 306

1 Answers1

19

Well, if you give it a manifest type:

int x, y = 1;

This declares two int variables, and initializes one of them. But local variable type inference requires an initializer to infer a type. So you're dead out of the gate.

But, suppose you meant to provide an initializer for both. It's "obvious" what to do when both initializers have the same type. So let's make it harder. Suppose you said: 

var x = 1, y = 2.0;

What is this supposed to mean? Does this declare x as int and y as float? Or does it try to find some type that can be the type of both x and y? Whichever we decided, some people would think it should work the other way, and it would be fundamentally confusing.

And, for what benefit? The incremental syntactic cost of saying what you mean is trivial compared to the potential semantic confusion. And that's why we excluded this from the scope of type inference for locals.

You might say, then, "well, only make it work if they are the same type." We could do that, but now the boundary of when you can use inference and when not is even more complicated. And I'd be answering the same sort of "why don't you" question right now anyway ... The reality is that inference schemes always have limits; what you get to pick is the boundary. Better to pick clean, clear limits ("can use it in these contexts") than fuzzy ones.

Brian Goetz
  • 90,105
  • 23
  • 150
  • 161
  • 5
    thank you, plz not that this is not one of the "why not just..." questions, I was 99% sure of the answer, but wanted a reliable source, well, you can't get *more* reliable than this. – Eugene Mar 07 '18 at 15:28
  • 1
    Java's decision to keep things simple is one of the main reasons I like the language. Less corner cases and syntax => easier to read/understand code. I'm also keenly watching the valhalla-dev mailing list to see what they're cooking up for value type constructors and the proposed `__WithField` operator (still seems kind of 'meh' at the moment). – Jorn Vernee Mar 07 '18 at 16:26
  • 1
    Hint: anything called something as ugly as __WithField is by definition a temporary known-terrible placeholder for something better. If it weren't "meh", that would be surprising. – Brian Goetz Mar 07 '18 at 16:41
  • I get that part, but I don't like the suggestion that it would be used like `this = this.__WithField(x = 10)` in a constructor (which evolved from `this.x = 10`). idk, doing constructors (in all their reference type glory) for value types just feels like trying a little too hard to "magic away" the differences between reference types and value types. Having some sort of separate 'initializer expression' (which translates to `vwithfield`s) just makes more sense to me then adding multiple meanings to constructors. Then you can just have the conventional `withX` method, instead of an operator. – Jorn Vernee Mar 07 '18 at 16:59
  • Sorry to bother you with that, I should probably just post to the mailing list. The character limit prevents me from _really_ explaining myself here any ways. – Jorn Vernee Mar 07 '18 at 17:23
  • 2
    I think you're jumping nineteen steps ahead to "but what will the language syntax be" when all of the work is currently focused on how it needs to be implemented in the VM. Any surface syntax at this point exists purely so we can write programs that exercise the VM, to validate whether the programming model works at all. – Brian Goetz Mar 07 '18 at 17:30
  • Well, the discussion was about syntax, and the semantics it documents, in this case: http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-February/003866.html But I agree that I'm jumping ahead (not much to do but speculate while waiting ;) ). – Jorn Vernee Mar 07 '18 at 18:07