Hi Karim, I wasn't aware before how this was supposed to work, but it appears ChucK treats a literal array as an array of the most specific type that encompasses all of its elements. Thats why an array of [SinOsc, SqrOsc, TriOsc] automatically turns into Osc[]. On the other hand it is indeed not possible to use an array as an array of its supertype. One reason for this is that x @=> A[0] should work for any UGen x and UGen[] A but would be invalid if A is actually Osc[]. This kind of error would be only detected at run-time and not at compile-time, breaking compile-time type safety. In your specific case you could take advantage of the first fact and do something this: [s0$UGen, s1, s2] @=> UGen A[]; But this doesn't generalize beyond determining the type of the array when it is defined literally. spencer On Wed, Jan 4, 2017 at 6:59 AM, Karim Sumun wrote:

Given the following declarations:

SinOsc s0; SqrOsc s1; TriOsc s2;

The following gives an error:

[s0, s1, s2] @=> UGen A[]; $ ... cannot resolve operator '=>' on types 'Osc[]' and 'UGen[]'...

But the following works fine: [s0, s1, s2] @=> Osc A[];

It is not a problem, but would like to understand this behaviour. It would seem that assigning to UGen[] would be ok because it looks like a superclass of Osc[].

Aaah! Is this to do with co/contra-variance?

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Spencer Salazar Doctoral Candidate Center for Computer Research in Music and Acoustics Stanford University spencer@ccrma.stanford.edu +1 831.277.4654 https://ccrma.stanford.edu/~spencer/