even more delegate sugar

[Don Clugston]

Oskar Linde wrote:
> Don Clugston wrote:
>> Tom S wrote:
>>> While we're at it, how about allowing the construct:
>>> methodName (arg, arg, ..., arg, { ... });
>>>
>>> to be equivalent to:
>>> methodName (arg, arg, ..., arg) { ... }
>>>
>>>
>>> and
>>> methodName ({ ... });
>>>
>>> to
>>> methodName {}
> 
> Just as I and others have suggested already. I really like it.
> 
>>>
>>>
>>> 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).
I don't know if this would be a big problem in practice - but it makes 
me a bit nervous.

What would you do with

methodName (int, void delegate(void) ... )
?

>> But an amazing feature of your proposal is that you could write
>> a function
>> void If(bool b, void delegate (void) f);
>>
>> and then write
>>   If( cond) { writef(xxxx); }
>>
>> which would behave just like the built-in 'if' statement (albeit 
>> without an 'else' clause). Interesting.
> 
> Indeed.

On reflection, an even more interesting example is variants of foreach, 
which I think would become completely redundant.