Record component type can be an inner class of a record

Dan Smith daniel.smith at
Tue Apr 28 16:53:33 UTC 2020

> On Apr 27, 2020, at 6:13 PM, John Rose <john.r.rose at> wrote:
> On Apr 20, 2020, at 3:32 PM, Dan Smith <daniel.smith at> wrote:
>> My point: there are no references to 'A' inside the body. The only reference to 'A' in this program unambiguously refers to the top-level A.
>> You seem to be assuming that there will be resolution problems involved in checking the implicit members. And my response is that it's not our job to perform name resolution for implicit members—they are defined more abstractly than that. Specifically, the return type of the 'a' method is the type referenced by the type name 'A' appearing after 'record B(' in the program, as it is resolved *at that location*.
> Perhaps this sort of question can be avoided if we ensure that
> desugaring pseudocode specifies that introduced occurrences
> of types are not re-resolved at their introduced points.  One
> way to do this (with overkill) is to make sure there are fake
> package prefixes on introduced occurrences:
> record R(A x) extends AnotherADeclarer { }
> (where A is fully qualified as pa.A)
> =>
> final class R extends AnotherADeclarer {
>   pa.A x;
> }

Unless AnotherADeclarer also declares a class named pa. :-)

There is no 100% reliable desugaring to Java syntax. But that's not a problem, because implicit members aren't expressed with Java syntax.

(This problem is not unique to records. For example, every interface has an implicit 'toString' member (the language doesn't have a concept of inheritance from Object). The return type of 'toString' is 'String', even if the interface has member classes named 'String' and 'java'. Another example: repeated annotations.)

More information about the amber-spec-experts mailing list