even more delegate sugar

[Don Clugston]

Oskar Linde wrote:
> Don Clugston wrote:
>> Oskar Linde wrote:
>>> Don Clugston wrote:
>>>> Tom S wrote:
>>>>> Then e.g. the 'dotimes' example from 'Lazy Evaluation of Function 
>>>>> Arguments' would become:
>>>>>
>>>>> void foo() {
>>>>>     int x = 0;
>>>>>     dotimes(10) {
>>>>>         writef(x++);
>>>>>     }
>>>>> }
>>>>>
>>>>>
>>>>> Which eliminates the need for lazy evaluation in this case, as it 
>>>>> simply uses a delegate. Moreover, it is more readable and concise 
>>>>> at the same time.
>>>>
>>>> Sounds nice, but nowhere near enough visual cues.
>>>> If you leave off a semicolon, the meaning completely changes.
>>>>   dotimes(10); {
>>>>    writef(x++);
>>>>  }
>>>>
>>>>   and
>>>>
>>>>   dotimes(10)
>>>>
>>>>   {
>>>>     writef(x++);
>>>>   }
>>>>
>>>> would both be valid code.
>>>
>>> Would they? (assuming there is no dotimes overload with only one 
>>> argument)
>>
>> I was not making that assumption. There's also:
>>
>> dotimes(int x, void delegate(void) y = { writefln("Surprise"); });
>>
>> (I think that providing a default values for any such trailing 
>> delegate would always create this situation).
> 
> You are correct, of course.
> 
>> I don't know if this would be a big problem in practice - but it makes 
>> me a bit nervous.
> 
> The fact that C has had this very same issue with if, while, for, et.al. 
> for centuries should work in favor of the proposal though.

Touché. I forgot about that.

Indeed
for (int=0;i<10;++i);
{
   printf("%d", i);
}
is valid C code, and the proposal is certainly no worse than that.

> 
>> What would you do with
>>
>> methodName (int, void delegate(void) ... )
>> ?
> 
> Yes, that is an interesting case. One could either:
> a) live with the ; changing the meaning of the code
> b) forbid the proposed syntax in the cases where a ; would change the   
> meaning of the code.

It would also be nice to be able to do something with the related example:
methodName(int x, void delegate(void) dg[] ... )

but I don't think it's practical.

methodName(7) { writefln("first"); } with { writefln("second")} with { 
writefln("third"); }

Unconvincing.

>> On reflection, an even more interesting example is variants of 
>> foreach, which I think would become completely redundant.
> 
> break would pose a problem though.

You're right.
Although foreach with opApply has the same problem.