On Thu, 16 Jul 2009 14:56:28 -0400, Jarrett Billingsley
<[email protected]> wrote:
On Thu, Jul 16, 2009 at 2:22 PM, Steven
Schveighoffer<[email protected]> 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
