even more delegate sugar

[Oskar Linde]

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.

> 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.

> 
>>> 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.

break would pose a problem though.