Dunno if this is a bug or a feature. Seems odd, though. Can someone explain what's going on? // Note that the following is perfectly legit float hx, hy; fun void h(float x, float y) { x => hx; y => hy; } // And this works without trouble float f_x[]; float f_y[]; fun void f(float x[], float y[]) { x @=> f_x; y @=> f_y; } // But when you elide the array declarations, you get an error: // NOT on the declaration line, but on the assignment of g_y: // [decl_test.ck]:line(17): cannot assign '@=>' on types 'float[]' @=> 'float[]'... // [decl_test.ck]:line(17): ...(reason: --- incompatible types for assignment) float g_x[], g_y[]; fun void g(float x[], float y[]) { x @=> g_x; y @=> g_y; // this is line (17) }
Rob;
Dunno if this is a bug or a feature. Seems odd, though. Can someone explain what's going on?
Yes, that seems like a bug. It's interesting how it only seems to affect g_y, which is the second declared array (and so the first one not declared in a bog standard way). I'd imagine this is yet another case of object types in arrays not being kept proper track of but oddly it seems that the type is properly kept track of when we do this; float foo[], bar[]; <<<bar>>>; It's only when we add assignment to the mix that the issues arrise I did some more tests and it seems like a initiation issue. Look at this; class Test { <<<"hi, my name is", this, "and i'm initiated">>>; } Test foo[2]; //this is fine Test bar[1], baz[1]; //hands up who wants to crash! File under; type and initialisation of arrays, a remarkably large category. Yours, Kas.
participants (2)
-
Kassen -
Robert Poor