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
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/