> On Apr 27, 2020, at 6:13 PM, John Rose <john.r.r...@oracle.com> wrote:
>
> On Apr 20, 2020, at 3:32 PM, Dan Smith <daniel.sm...@oracle.com> 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.)
