Annotating lambda expressions

[Brian Goetz]

> OK, but it's precisely the fact that inner classes are declarations that
> allows them to be annotated, because for declarations we specify the
> binary name, membership, and other artifacts of translation. No such
> spec for the translation of expressions (or statements) -- and I think
> it's generally regarded as a feature-not-a-bug that compilers have great
> freedom in translating lambda expressions.

Quite so.  Compilers should have freedom how they translate lambda 
expressions, which is why this is outside the scope of the 
specification.  This means that there's not a *reliable* place in the 
classfile to put these annotations.  You've suggested a *convenient* 
place to put them -- which works as long as we don't want to change our 
translation strategy (and are willing to mandate it for other compilers.)

I get why that seems reasonable -- half a loaf seems better than none 
when you're hungry -- but let's follow it through.  What happens when we 
*do* want to change the translation strategy?  Do you think people won't 
then howl because we "broke" their programs even though they rely on a 
completely unspecified translation strategy?  They'll say "but there was 
no other way to do it", and proceed to complain about how we 
gratuitously broke their programs.

So if we were to do this, we'd essentially be locking ourselves into the 
current translation strategy forever.  Unless we're going to go all the 
way (full reflection over all program elements, not just declarations), 
it's far better to leave the line where it is (can annotate declarations 
and type uses, but not expressions), than to blur the line in this way 
for the sake of the use cases at the margin.  (And remember, when you 
move the margin, new marginal use cases will come into view.)