On Thu, 06 May 2010 14:40:17 -0400, bearophile <[email protected]>
wrote:
Kagamin:
Since sin's result is not an array,<
I am not sure, but I presume here Don was talking about a dispatch of
the sin to all items of an array, so its result is another (new or
mutated in place) array.
Bye,
bearophile
That presumes a transform of the form: sin(y[]) => map!sin(y). However,
this creates unnecessary temporaries which are one of the main things
array ops is supposed to avoid. So this is a vote against sin(y[])[].
Also, if sin(y[]) returned a lazy/eager array then auto t = sin(y[]);
should be valid, but auto t = x[] + y[] is not currently valid. So this is
a vote against sin(y[])[].
As a related note, what do people think of array ops for generic ranges
(assuming they support length, etc)?
