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 <su...@pobox.com> 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 spen...@ccrma.stanford.edu +1 831.277.4654 https://ccrma.stanford.edu/~spencer/
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
