Custom Blocks

[Robert Jacques]

On Tue, 10 Aug 2010 06:59:11 -0400, Mafi <mafi at example.org> wrote:

> Am 10.08.2010 05:21, schrieb Andrei Alexandrescu:
>> Chris Williams wrote:
>>> I'm not sure whether the design of D 2.0 has stabilized as yet, but if
>>> not,
>>> I would like to suggest the ability to create custom block types.
>> [snip]
>>
>> FWIW we've been talking a long time ago about a simple lowering - if the
>> last argument to a function is a delegate, allow moving the delegate's
>> body outside of the function:
>>
>> fun(a, b, c) { body }
>>
>> |
>> V
>>
>> fun((a, b, c) { body });
>>
>> As far as Walter and I could tell, there are no syntactical issues
>> created by such a lowering. But we've been wrong about that in the past
>> (me 10x more often than him).
>>
>>
>> Andrei
> Hi,
> I don't want to be inpolite but what if fun returns a delegate which  
> accepts a delegate and fun is overloaded (the delegate parameter is  
> optional):
>
> void delegate(void delegate()) fun();
> void delegate(void delegate()) fun(void delegate());
> ...
> fun(){...} //does this result in void or void delegate(void delegate())
> ...
>
> It's the same as with property if they are allowed to call with parens.
> But this is a very unlikely to happen. I don't even know if delegate are  
> allowed to take delegate as parameters.

You're not being impolite, this is exactly what Andrei is looking for and  
delegates can take delegates as parameters. Although, you can't call  
delegates without (), so my gut says "fun {...}" would have to resolve to  
"fun(void delegate())". To use "delegate(void delegate()) fun()" the  
syntax would be "fun()() {...}". In general, overload ambiguities like  
these are allowed inside a module, but should be hijack errors when source  
coming from multiple modules.