Rob;

[2] For "immediate" data types (ints, float), => and @=> are identical: they move the data, not the pointer.  This is why
       int foo;
       int bar;
       foo @=> bar;  // assigns 0 to bar
       1 => foo;      
doesn't modify bar -- bar will still have a value of zero.

Any disagreements?

Yes, sorry but I have to disagree. I don't see why I shouldn't be allowed to have primitives reference each other; I don't see any use in two operators accomplishing the same thing and when we'd want another type of behaviour we'd need to encapsulate the variable in a array.

Sadly the online language specification doesn't have a great deal to say on this but the manual states; "similarly, reference assignment duplicates a reference to an object and assigns the reference to a reference variable. The object itself is not duplicated. All ChucK object assignments are reference assignments."

Sadly (for me) the ChucK parser disagrees with me and feels integers aren't objects, to demonstrate;

Object foo;
int bar @=> foo; //this fails

True; the manual exclusively covers objects but it doesn't actually define what should happen in this case at all. It's my opinion that either @=> and => should do something different  when applied to primitives or the assignment should at the very least cause a warning. I'm leaning towards the first option as I can see uses for it. I might have a shred that periodically sends "float foo"  to the frequency of my instrument. I might then later want to assign some other variable to foo so that this shred will then send whatever that variable holds to this frequency.

The chuck operator "=>" is "masively overloaded" and that's a good thing (hopefully) but it makes no sense to me to also overload "@=>" to also mean "=>" under certain conditions. To address Hans's point, the chuck operator can indeed be used on types that can be assigned as well; for example to connect UGens or to chuck Events to now. These things aren't mutually exclusive; Events and UGens can both be assigned and chucked to eachother.

Clearly there is no issue with dis-allowing certain operators on certain objects, we can't use "%=>" on a Gain, for example. It's not clear to me why @=> as applied to primitives is a exception here and is instead overloaded to mean "=>". It's no huge issue but I would like to understand why it is like it is.

Yours,
Kas.