This is an interesting one that has cropped up. I'm curious if
this is because the differences between a fixed/dynamic arrays.
Working around it is easy enough but that it even does it is an
annoyance.

    I'm not seeing this exact problem in the archives, and I am not
sure if it's in the tracker already under a different
name/identifier. :(


---
module internal_error_485;
/*Internal error: ..\ztc\cod3.c 485
     happens when class (or inherited) have one return a string (to
convert) and the other with the workaround.

     Oddly it isn't doing auto conversion/shortening on a string of
a known size.
*/

alias immutable(char[4]) string4;
class x {
     string4 f() {
//      return cast(string4) "HEDR";    //Internal error:
..\ztc\cod3.c 485
//      return cast(string4) "HEDR".ptr;  //same

//      return "HEDR";      //implicit conversion fails
//      return string4("HEDR");  //temporary object doesn't
create properly for returning.

         string4 x = "HEDR";
         return x;
     }
}

class z : x {
     override string4 f() {
       return "brk_";  //Internal error: ..\ztc\cod3.c 485
//    return cast(string4) "brk_";  //Same error

//    following works... but...
//    string4 x = "brk_";
//    return x;
     }
}

---

    it also breaks the same way if the base class returns the
string
and the inherited class returns the converted/long steps.

http://d.puremagic.com/issues/show_bug.cgi?id=7254 maybe?

-Steve

On Wednesday, 25 April 2012 at 12:43:39 UTC, Steven Schveighoffer wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=7254 maybe?

 Maybe... but it shouldn't be the wrong return; at least being a static length known at compile-time should convert to char[4]. I'm not sure how try/catch would make a difference either. But being as making a temporary to get the compiler to work around it means it isn't a critical problem.

 If these are related though, I could post my code there they are breaking at different points.