On 2010-05-07 01:34:39 -0400, "Robert Jacques" <[email protected]> said:
On Fri, 07 May 2010 00:13:04 -0400, Jason House
<[email protected]> 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.
--
Michel Fortin
[email protected]
http://michelf.com/
