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 <sumun@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

+1 831.277.4654