That's a borderline enhancement request. It might potentially break code too, e.g. this currently works:

-----
class D
{
}

class C : D
{
    static class D
    {
    }
}
-----

With the enhancement this would have to become a conflict, although the workaround would be easy: one could use 'class C : .D' (dot expression) for the global class and 'class C : D' for the nested one. But I'm not fond of such lookup rules where something in an inner scope ends up conflicting with an expression in an outer scope.

Well I don't think I've ever tried to use either of these samples so I don't have a strong opinion either way.

(In reply to comment #1)
> That's a borderline enhancement request.

No, it is a bug report. C.D is a perfectly fine base class.

> It might potentially break code too,
> e.g. this currently works:
> 
> -----
> class D
> {
> }
> 
> class C : D
> {
>     static class D
>     {
>     }
> }
> -----
> 
> With the enhancement this would have to become a conflict,

I am not arguing for any enhancement that would change the meaning of the above code.

> although the
> workaround would be easy: one could use 'class C : .D' (dot expression) for the
> global class and 'class C : D' for the nested one. But I'm not fond of such
> lookup rules where something in an inner scope ends up conflicting with an
> expression in an outer scope.
> ...

I generally like shadowing, but it would indeed be utterly pointless to look up a classes' parents inside its own scope.

(In reply to comment #2)
> I am not arguing for any enhancement that would change the meaning of the above
> code.

Ah, so you want this to work:

class C: C.D{static class D{}}

but this to fail:

class C: D{static class D{}}

And the following would stay as-is:

class D { } class C: D{static class D{}}  // inherits global D

If that's so then this is reasonable.

*** Issue 10759 has been marked as a duplicate of this issue. ***

Fix for ICE:
https://github.com/D-Programming-Language/dmd/pull/2449

Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/55d944d9e06c3dc7d00a61adcdefbc0048a2e283
fix Issue 10616 - class C: C.D{static class D{}} does not work

https://github.com/D-Programming-Language/dmd/commit/1ec9aa41bf33cf1f92fc6f60bbe5244e2898a7b7
Merge pull request #2449 from 9rnsr/fix10616

Issue 10616 - class C: C.D{static class D{}} does not work

ICE fixed, but the bug report will remain open for the rejects-valid code.

*** Issue 10887 has been marked as a duplicate of this issue. ***

(In reply to comment #7)
> ICE fixed, but the bug report will remain open for the rejects-valid code.

The members of class X are unknown during the resolution of the class X hierarchy. In other words, it's a limitation that whole class hierarchy must be already known when class members being iterated.

This is necessary to test self type inside class member scope.

class B {
    void foo() {}
}
class C(T) : T
{
  /* if C!T inherits B, override B.foo */
  static if (is(C : B))
    override void foo() {}
}
alais CB = C!B;

To return 'true' at the static if condition, the fact "C!B inherits B" should be already known.
For that, compiler determines whole class hierarchy before each class members semantic.
And, it is the exact behavior that current dmd does.

---

By the current semantic strategy for classes, the OP code won't be compiled. So this is not a rejects-valid bug.
To accept the OP code, we should drastically improve semantic analysis mechanism.

Change the importance to 'enhancement'.

@ibuclaw created dlang/dmd pull request #14826 "dmd.aggregate: Define importAll override for AggregateDeclaration" fixing this issue:

- fix Issue 10616 - forward reference error with class C: C.D{static class D{}}

https://github.com/dlang/dmd/pull/14826

THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/18628

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB