Automatic Foreach

[Bill Baxter]

janderson wrote:
> Bill Baxter wrote:
>> janderson wrote:
>>> Bill Baxter wrote:
>>>> janderson wrote:
>>>>> What do you think?
>>>>
>>>> I think it's already hard enough to figure out what's going to get 
>>>> called by something like foo(array)
>>>>
>>>> It could be
>>>> - foo(int[] x)
>>>> - foo(int[] x...)
>>>> - foo(T)(T x)
>>>> - foo(T)(T[] x)
>>>> - foo(T...)(T x)
>>>> - struct foo { static foo opCall(int[]); }
>>>> - struct foo { static foo opCall(int[]...); }
>>>> - struct foo { static foo opCall(T)(T x); }  etc
>>>> - or struct Foo with non-static opCall on instance foo
>>>> - or all the same stuff on class  ...
>>>>
>>>> So I don't think another meaning for foo(array) is really helpful.
>>>>
>>>> I *do* like the idea of an expression (not a statement) that has 
>>>> foreach-like abilities.  But I think it should come with some 
>>>> distinguishing syntax.
>>>>
>>>> In Python it's just [expr(x) for x in array]
>>>> Which resonates with Pythons normal loopoing:
>>>>    for x in array: expr(x)
>>>>
>>>> So direct translation of that idea to D would be
>>>>    [expr(x) foreach(x; array)];
>>>>
>>>> Seems not so terrible a syntax to me.
>>>>
>>>> --bb
>>>
>>> I think I prefer:
>>>
>>> foo(array[]);
>>
>> I think that already means call foo with a full slice of array, 
>> doesn't it?  Anyway, even if it doesn't you can overload opSlice() 
>> currently so that array[] can mean anything you want it to.
>>
>> --bb
> 
> That's the point though.  If there's already an overload available then 
> that should be used.  It allows you to come along later and write 
> specialized behavior.

Ok I suppose.  As long as you're aware what your proposing will break 
existing code,  which means the barrier for accepting the proposal will 
be a lot higher.

--bb