Hi,

I got an unexpected error message ("no property X for type Y") and got it down to the following minimal test case:

#module test;
#struct A { }
#struct B {
#  test.A a;
#  int test;
#}
#void main() {}

Compiling with DMD 0.169 gives:

test.d(4): no property 'A' for type 'int'
test.d(4): test.A is used as a type
test.d(4): variable test.B.a voids have no value

The "test" on line 4 is interpreted as a field name (strange place for a field name) instead of the module name. Commenting either line 4 or 5 gets rid of the errors.

Obviously, using "test.A" makes no sense here, but in the original project an imported module conflicted with a field of the struct.

I think the code is valid, since there seems to be no conflict between a module name and field names if I comment only one of the lines in the struct.

L.

"Lionello Lunesu" <lio@lunesu.remove.com> wrote in message news:eh00d0$7gc$1@digitaldaemon.com...
> Hi,
>
> I got an unexpected error message ("no property X for type Y") and got it down to the following minimal test case:
>
> #module test;
> #struct A { }
> #struct B {
> #  test.A a;
> #  int test;
> #}
> #void main() {}
>
> Compiling with DMD 0.169 gives:
>
> test.d(4): no property 'A' for type 'int'
> test.d(4): test.A is used as a type
> test.d(4): variable test.B.a voids have no value
>
> The "test" on line 4 is interpreted as a field name (strange place for a field name) instead of the module name. Commenting either line 4 or 5 gets rid of the errors.
>
> Obviously, using "test.A" makes no sense here, but in the original project an imported module conflicted with a field of the struct.
>
> I think the code is valid, since there seems to be no conflict between a module name and field names if I comment only one of the lines in the struct.
>
> L.

I can understand why this happens, but I don't know if there'd be an easy fix (in the compiler) for it.  Basically, the names of the struct members are added to the struct's symbol table before their types are checked for correctness.  So by the time a's type is checked, "test" has already been added to B's symbol table, so it finds B.test before it goes to the module-level scope.  This cannot really be changed without introducing some very weird symbol lookup rules into the compiler.

Strangely, what I thought would work, doesn't:

struct A {}
struct B
{
    .test.A a;
    int test;
}

now it gives the error "identifier 'test' of 'test.A' is not defined."  I don't know what that means.  But in any case, you wouldn't really be accessing FQNs of current module members that much, so I guess not many people would run into this.

I don't know if it's a bug so much as just a weird issue.

Jarrett Billingsley wrote:
> Strangely, what I thought would work, doesn't:
> 
> struct A {}
> struct B
> {
>     .test.A a;
>     int test;
> }

Actually, that's exactly how I managed to fix it! Apparently it doesn't work in the simplified test case, but when using two files (as in my project) the leading dot fixes the problem:

[test.d]
struct A {}

[main.d]
import test;
struct B {
  .test.A a;
  int test;
}

I agree that there won't be many people with this problem, but I would expect types and field names / variables to be in separate name lookup lists.

L.

Lionello Lunesu wrote:
> Jarrett Billingsley wrote:
> 
>> Strangely, what I thought would work, doesn't:
>>
>> struct A {}
>> struct B
>> {
>>     .test.A a;
>>     int test;
>> }
> 
> 
> Actually, that's exactly how I managed to fix it! Apparently it doesn't work in the simplified test case, but when using two files (as in my project) the leading dot fixes the problem:
> 
> [test.d]
> struct A {}
> 
> [main.d]
> import test;
> struct B {
>   .test.A a;
>   int test;
> }
> 
> I agree that there won't be many people with this problem, but I would expect types and field names / variables to be in separate name lookup lists.
> 
> L.

Interesting.  So, the global-scope operator fails on the current module's namespace, but succeeds on any other (thankfully).  Smells a little like a minor bug to me: it should be perfectly happy with the current module.

-- Chris Nicholson-Sauls