For some reason, if DMD comes across an undefined identifier being used as a class, it will complain about that, but it will then assume that it is of type "int" for the rest of the lexically enclosing block.  For example, the code:

void main()
{
    X.something();
}

Gives the errors:

dtest.d(3): undefined identifier X
dtest.d(3): undefined identifier X
dtest.d(3): no property 'something' for type 'int'
dtest.d(3): function expected before (), not 'int'

You'll notice that the last error even treats "something" (or maybe it's treating "X.something") as an int!

I surely can't see any benefit or reason to this weird "assume it's an int" behavior.  It makes for some confusing (and redundant - four errors for every time this happens) errors.

Jarrett Billingsley wrote:
<snip>
> void main()
> {
>     X.something();
> }
<snip>
> dtest.d(3): function expected before (), not 'int'
> 
> You'll notice that the last error even treats "something" (or maybe it's
> treating "X.something") as an int!

It's treating X.something as an int.

> I surely can't see any benefit or reason to this weird "assume it's an int"
> behavior.  It makes for some confusing (and redundant - four errors for
> every time this happens) errors.

I agree.  It seems that the semantic analysis lacks an 'invalid expression' type, using 'int' as a substitute (seems an arbitrary choice).  This is pointless - why not just create this 'invalid expression' type and use it?  Presumably when an expression depends on an invalid subexpression, the semantic analysis would then consist of propagating the 'invalid expression' type upwards without reporting an error.

It would still SA _siblings_ of invalid expressions, so that

    X.something(24 / "abc");

would report two errors (undefined error X; incompatible types for / operator) and only those two.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.