Bug 3537 – Casting objects with alias this takes the subtype

interface I { } class A : I { int x; alias x this; void f() { auto i = cast(I) this; // ouch } } Should work but doesn't: Error: e2ir: cannot cast this.x of type int to type hello.I The cast can be outside -- still the same error: void main() { auto a = new A; auto i = cast(I) a; // ouch }

This is designed behaviour. See documentation improvement Issue 11481.

(In reply to comment #1) > This is designed behaviour. See documentation improvement Issue 11481. It makes dynamic casts impossible, it has to be changed. Here's a better example: ---- class A { int i; alias i this; } class B : A {} void main() { A a = new B; B b = cast(B)a; // test.d(12): Error: e2ir: cannot cast a.i of type int to type test.B } ----

@Denis: Please never close any issues where the error message includes "e2ir", as these are in fact ICEs (the frontend accepted something the glue code does not understand) and thus bugs regardless of what the intended behavior is.

(In reply to comment #3) > @Denis: Please never close any issues where the error message includes "e2ir", > as these are in fact ICEs (the frontend accepted something the glue code does > not understand) and thus bugs regardless of what the intended behavior is. First, didn't think it's an ICE as it's so common and even Kenji create issues with `e2ir` errors without ICE keyword. Second, your words mean I can open e.g. "`byte` must be convertible to `Object`" issue and nobody can close it as the conversion results in ICE. ) So I can't accept it. But I will open "[e2ir]" ICE issues from now for such unreported minor ICEs. Issue 11485 is for this one.

(In reply to comment #4) > Second, your words mean I can open e.g. "`byte` must be convertible to > `Object`" issue and nobody can close it as the conversion results in ICE. Yes, such a report shouldn't just be closed as invalid. The title might be changed to something more fitting, however, and it could be marked as a duplicate of another entry describing the root cause.

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

Marking this one as a duplicate, as there already is a PR referencing 6777 *** This issue has been marked as a duplicate of issue 6777 ***