JLS tweaks

[Brian Goetz]

So, none of these are really "tweaks".  And of these, only #1 is 
actually small.  Some very quick comments.

> *Idea #1: Allow final index variable in Iterable loops*
OK, this is a pretty tiny change.  Low cost, low risk -- but also low 
reward.
> *Idea #2: Allow non-this code prior to super()/this() call in 
> constructors*
This is well-traveled ground; this request has come up, and been shot 
down, many times.  If anything, the language spec is already too loose 
here, allowing too many unsafe operations (e.g., calling virtual methods 
from constructors, allowing constructor to publish 'this', etc) and this 
would make this problem dramatically worse.

Worse, of the cases where people claim they need this feature, they tend 
to be wrong most of the time, both underestimating the safety costs and 
overestimating the need.  In your example, you can accomplish what you 
want both safely and without redundant computation with a combination of 
a public factory and a private constructor.  Weakening the language 
safety is not the answer.
> *Idea #3: Allow generic type declarations wherever normal type 
> declarations are allowed*
Obviously "wherever normal type declarations" is broader than you mean.  
What you're looking for is the ability to "uncapture" a captured 
variable, giving it a name.  As you've pointed out, generic methods 
already provide you the ability to do that, and what you're asking for 
is do to that 'inline' in a block of code.  My recommendation is to try 
and take this to the next step (a more detailed analysis); I think 
you'll find you'll run into complexity at multiple levels.
> *Idea #4: Teach compiler that an exception means the last assignment 
> statement was not executed*
>
I'm kind of sympathetic here.  Specifying "unless the last statement 
is..." is kind of messy, increasing the cost.
> *Idea #5: Allow enum types to have generic type parameters*
Another frequent suggestion.  I agree it would have been better if it 
were done this way initially, and the cost would have been low. The cost 
of doing this now in a binary-compatible way would be higher.
> Some of these obviously would take more compiler work than others. 
> However, I want to make sure to keep separate feedback based on 
> practical concerns (e.g., "too hard to implement") vs. more 
> fundamental language issues that I may be missing.

So, summary:

1, 4: practical, but probably low return on investment
2: bad idea
3: bigger than you think
5: desirable, but compatibility risks lurk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140303/26a74516/attachment-0001.html