closures

[Steven Schveighoffer]

On Thu, 16 Jul 2009 14:56:28 -0400, Jarrett Billingsley  
<jarrett.billingsley at gmail.com> wrote:

> On Thu, Jul 16, 2009 at 2:22 PM, Steven
> Schveighoffer<schveiguy at yahoo.com> wrote:
>>
>> What about syntax to force closure behavior (on or off)?  Not that I  
>> have
>> any to suggest, but if the compiler is going to remain ignorant about  
>> escape
>> analysis, then we should be able to supply the intelligence, and  
>> hacking an
>> extra wrapper function to force behavior seems... well, hackish :)
>
> There already is, at least for turning closures off.

Yes I'm aware.   But that has some limitations.

For example, if I truly want my delegate to be a variable, I have to  
decide which delegate to use at the time I'm calling the function.  I  
can't store the delegate and then call the function later.

Also, forcing a closure for the reasons discussed in this thread would be  
useful.

I think the philosophy that D has on say const would be beneficial here:

1. When the compiler can prove the code is correct, allow it.  e.g.  
implicit cast of a const value type to a mutable value type.
2. When the compiler can't prove, do the safest thing.  e.g. e.g. const  
could be a pointer to mutable, but compiler isn't sure, so don't allow  
implicit cast.
3. When the user knows more about the situation than the compiler, allow  
override.  e.g. explicit cast away const is allowed, or explicit cast to  
immutable.

The same thing could be applied to closures:

1. Calling a function with a delegate where the arg is scope is allowed.
2. Assigning a delegate to a variable causes a closure.
3. The user can specify that a delegate does not need a closure.

-Steve