Is [] mandatory for array operations?

[Robert Jacques]

On Fri, 07 May 2010 07:51:11 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2010-05-07 01:34:39 -0400, "Robert Jacques" <sandford at jhu.edu> said:
>
>> On Fri, 07 May 2010 00:13:04 -0400, Jason House   
>> <jason.james.house at 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?