The future of lambda delegates

[BCS]

Lionello Lunesu wrote:
> kris wrote:
> 
>> I'm hoping there's another option, better than both the above (or the 
>> above combination) ~ it's seems apparent that neither present an ideal 
>> resolution
> 
> 
> Delegates are a pretty advanced programming technique. I don't think it 
> would be bad solution to just let the programmer mark the exceptional 
> cases. At least until a fail-safe general solution becomes available.
> 
> L.

At some point you have to just let the man shoot himself in the foot. 
You can't stop him. So the best we can do is stop the easy cases and put 
big warning labels on the hard ones. That is, make them official 
undefined behavior cases.

If I wanted a really robust systems, I would use a language that only 
uses heap frames. And has runtime type checking. And a load of other 
time hogging safety features. All of which I'm glad D *doesn't* have.


Alternative solution:

Requirer the programmer to write "correct" programs. Then, in debug 
builds, check for errors at run time.

One options for doing this check is this:

In debug builds, put a guard word at the start of each stack frame for 
every function with delegates. When the function returns, clear the guard.

All delegates are now replaced with something that looks like this (in 
sudo code):


&(
class {
	int guard;		// storage for the guard
	R delegate(A...) dg;	// storage for the actual delegate

		// whatever args are needed
	R test(A... args)
	{			// test the guard
		assert(guard == dg.this.__guard);
				// chain to the delegate
		return dg(args);
	}
       }
).test


The guard word is pulled from a counter so it will be unique.