On Fri, 07 May 2010 07:51:11 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2010-05-07 01:34:39 -0400, "Robert Jacques" <sandf...@jhu.edu> said:
On Fri, 07 May 2010 00:13:04 -0400, Jason House
<jason.james.ho...@gmail.com> wrote:
Robert Jacques Wrote:
given
real foo(real value) {...}
and
real[] foo(real[] value) {...}
what should happen with the follow line of code:
x[] = foo(y[]) + z[];
That can be interpreted in either of the following ways:
foreach(i) x[i] = foo(y[i]) + z[i];
OR
auto F = foo(y[]); foreach(i) x[i] = F + z[i];
The 2nd would be a compile error, so it must be the first.
Well, this adds a bunch of complexity, since a combinatorial number
of statements have to be evaluated and a match picked.
And then there's the ambiguous case:
x[] = foo(y[]);
Which is an example of x[] = y; vs x[] = y[]; problem.
True. The problem comes from the overloaded meaning of []: "slice" or
"array op"? I'm not sure whether this is a problem or not. We already
have overloaded functions which can be ambiguous. The compiler solves
this with a compile-time error; perhaps it should be the same here.
True, but other overloaded function you can resolve by a) assigning to a
temporary of the desired type or b) using the qualified name. With array
ops I must using the [] operator and therefore must be ambiguous.
Given that y[] is really syntactic sugar y[0..$], one option would be to
bite the bullet an make [] a dedicated array op/vectorize operator. This
would pave the way for using array ops with user defined types (e.g.
matrices and ranges). However, the downside to this is that user types
would loose the x[] = y; and y[] operator overloads. Classes can use x[] =
y to mean copy assignment (since x=y is a ref assignment). Collections may
use y[] as sugar for a .all() method/property. Are there other use cases?