Understood; restricting to methods only here was probably gratuitously
bespoke. I would indeed like to clean this up too (though, while it
might sound like a "one line change to the compiler", it is actually way
more work than it sounds, because it affects both JLS and JVMS, so
requires code
The recent thread about "cleaner nesting" reminded me of a related language
constraint that has caused me a bit of a headache recently, and I wonder if
we can clean it up at the same time.
Somewhat recently, interfaces have gained the ability to have private
methods, for use as helpers in
I agree it is silly to put these annos on record components. On the other
> hand, I am not sure the spec should prohibit them -- seems more the sort of
> thing an IDE should say "hey, that was probably dumb, are you sure you want
> that?"
>
> In any case, it is reasonable for a compiler to error
Nice catch, Tagir. Historically the @Target meta-anno has been strong
enough to keep people from putting annos in the wrong place, but with
the "clever" handling of annos with records (accepting any of the target
types an anno can be reasonably pushed down to), we don't have any way
of saying
Hello!
Current spec draft 6.3.2 [1] says nothing about the interaction of
pattern scopes and labeled statements, and reading spec 14.5 and 14.7
I conclude that the labeled statement is a kind of statement.
E.g.:
public static void main(String[] args) {
Object o = "hello";
L0:
Hello!
It appears that it's possible to annotate record component as
@Override or @SafeVarargs, and spec doesn't explicitly forbid this:
record Test(@SafeVarargs int x, @Override int y) {}
In these cases, it's assumed that the annotation propagates to the
accessor method. However, having
