eduard;


What do you think?

I tried a few things but I'm a bit stuck here as well. Right now, unless I'm very mistaken, this looks to me like it's indeed wrong and another expression of something being wrong in the type-system where arrays are concerned.

Here in particular array types don't seem respect extending of classes, type-wise. I Hacked up your class structure for a bit, having Point1D extend Point and Point2D extend Point1D, etc but that didn't help.

I ended up writing a small trivial test case. I feel this should work, it should print a series of 3 zeros.... yet it doesn't;

//==================-8<======================-
class bar
    {
    int value;
    }
   
class baz extends bar
    {
    }

baz foo[3];

fun void print( bar p[])
    {
    for(0 => int n; n<p.cap(); n++)
        {
        <<<p[n].value>>>;
        }
    }

print(foo);
//==========================

To prove my case, consider this trivial case;
//========================
class bar
    {
    int value;
    }
   
class baz extends bar
    {
    }

baz foo;

fun void print( bar p)    <<<p.value>>>;
   
print(foo);
//===================

...which does fly; foo is a "baz" which is in turn a "bar". Elements of arrays of this type should be the same.

I suspect this is a clearer example of a case I ran into some months ago but it wasn't clear to me back then what aspect caused the issue (reported back then straight to Ge for reasons I can't quite recall). I'd say the issue isn't passing arrays as arguments as such (this is fine) but the type of array elements that are instances of classes of that extend another class. Their type will only become a real issue when they are passed to functions as variables of the mother type, hence your issue here.

I'm a bit surprised this doesn't seg-fault, I think mine did back then.

Anyway; I say it's a type-system bug in arrays.

Nice catch, I'm fairly sure this one has been in there for a while but was hard to pinpoint. It seems to be a good season for hunting!

Yours,
Kas.