Towards cleaner nesting

Dan Smith daniel.smith at
Fri Jan 10 21:38:18 UTC 2020

> On Jan 9, 2020, at 8:02 PM, Brian Goetz <brian.goetz at> wrote:
> So variable initializers can have expressions in them, which can have statements in them

My mental model was to fudge and call those "instance initializers". :-) (And then I debated dropping the asterisk on instance/local variables, and didn't, but I guess for consistency should have, because the initializers are the only place variable references can live.)

>> - interfaces can't directly contain instance initializers/constructors, instance/local variables, or inner classes (maybe)
> In order to have inner classes in an interface, we'd have to have a non-static modifier, since nested classes in interfaces are allowed now and are implicitly static.

Yep. But letting syntax drive this decision doesn't seem very much in the spirit of "anything can be nested in anything", so maybe new syntax is worth it to iron out this wrinkle? Or not—maybe "no new syntax" is where we draw the line.

>> - annotation types can't directly contain things prohibited in interfaces, or instance/local methods (maybe)
>  - currently annos cannot have fields, default methods, or static methods -- this still seems a reasonable restriction.

Why? I mean, I don't really care all that much, but if we're removing ad hoc restrictions, this one (no methods) certainly seems ad hoc. We don't even need new syntax.

> Your list doesn't treat constructors, either as "what can contain them" (pretty clear that's classes/records/enums only), or as "what can they contain" (could a constructor have, for example, a local method or a local class.)

It does, in fact. But lumped in with instance initializers, as a kind of "method declaration", so you probably overlooked it.

As a starting point, we can say anything can contain a constructor, and constructors can contain anything. And then there are restrictions:
- interfaces/annotations/methods of any kind can't contain them
- they can't contain things prohibited in regular methods

I don't see any reason to make constructor bodies more restrictive in terms of nesting than method bodies. Local classes are already legal.

More information about the amber-spec-experts mailing list