Inline execution of a lambda expression or anonymous delegate

I had an idea I wanted to try to exploit that would make my VB.NET expression a bit more, well, expressive.

The way I built my expression builder, essentially you pass in a valid VB.NET expression and the expression builder sticks it onto the end of a Return statement inside a static method of a new class, which it then compiles with the stock VB.NET code compiler. Then I use reflection to dig out the compiled method and returns a Func<bool> that invokes the method, returning the result.

This works great for its intended purpose, but it unfortunately restricts my expressions to being, well, expressions. Boolean expressions. Which means they can't do a whole lot of processing, or whatever. That's okay - I don't really *need* all that much. But I enjoy a challenge, and I thought to myself 'Self, why don't we try to use an inline lambda!'

Great idea - except you can't INVOKE a lambda inline. Example:

bool x = ( () => true ).Invoke();

Doesn't work. Operator '.' cannot be applied to operand of type 'lambda expression'. 'Fine,' says I, 'I'll use an anonymous delegate!'

bool x = ( delegate { return true; } ).Invoke();

Operator '.' cannot be applied to operand of type 'anonymous delegate'. Argh. So as far as i'm aware, this is impossible, probably by design. I'll have to ask Eric Lippert about it, since he's been doing his C# design rationale posts lately.

File operations and temp folders...

This is a problem I've seen before in many places, and it seems like good practice (or at least it must have at some point) - but for me it seems to cause more harm than good.

Many program (Internet Explorer for file downloads, certain ZIP utilities, etc) perform file operations in a temporary folder, then copy the results of the operation to the ultimate destination.

I can see why this makes sense. Depending on the operation, allowing the user to muck with the file during processing can cause data loss, errors, mini-black holes, etc. But when the resulting file is very, very large, the subsequent copy can take forever. Additionally, if there isn't enough space on the destination, then instead of failing fast and reporting the file allocation error, we have to wait until the end of a potentially expensive operation (like unzipping a 12 gig file from an archive) before we find out. In fact, this practice makes such a problem more likely because the space requirements are doubled in order to facilitate the copy.

I'm really just ranting here rather than offering a fix for the problem - the only fix I could possibly suggest would be to avoid doing this at all. If you must, however, make it an option for the user to override, allowing said user to take responsibility for his/her own file system.

*ahem* STOP PROTECTING ME FROM MYSELF.