closures continued.. ByRef, ByVal and ()

Parenthesized expressions (more on Closures)

@ Head — Mon, 24 Apr 2006 04:26:49 GMT

since Scott said such nice things about my last post on closures, I thought I'd add some quick references...

re: closures continued.. ByRef, ByVal and ()

bill — Tue, 11 Apr 2006 01:52:45 GMT

Let me address this question first:

> It also raises the question of what (x + y)
> would do -- would that uncapture both x and y?

I think what you are sayign there is actually much of what I was sayign, in that we need to move away from the use of just ()'s. If you adopted the (ByVal o) syntax there could not be that ambiguity.
You couldn't have (ByVal x + y).
It would have to be (ByVal x) + y
Syntatx like (ByVal (x + y)) would be illegal because x + y is an expression that produces a r value already.

I definetly disagree on the idea it should be r values instead of l values by default. That's jsut going to make it more confussing. I'd like to hear your arguements why you think it should be r. I presented some in my previous blog entry on captures but came to the conclussion that l values were preferable.

As to the parens with the capture (that is parens with the ByVal keyword added <g>), I think it does actually make a difference in what the compiler can do. The ()'s means a temporary variable is created, and as such the VB compiler can treat the compiler created variable differently from the code written variable, allowing things such as escaping out of the issue of the local variables insid a loop. Because the variable is a compiler generated one, you'd know there is no need ot link that to the original code, rather you'd use it to instantiate a value in the anon delegate's generated class.

to me, the (ByVal o) means the same as *ptr instead of **ptr in the effect it has on the code.

re: closures continued.. ByRef, ByVal and ()

Paul Vick — Tue, 11 Apr 2006 01:21:46 GMT

I think you're confusing two different things. In the case of expressions being passed to reference parameters, the real feature is that we allow you to pass r-values to reference parameters by creating a temporary to hold the value. This allows you to pass (x) to a reference parameter, but it also allows you to pass the literal 10 to a reference parameter. There's really nothing special about the parenthesis except that they, by their nature, always produce a r-value.

The parens don't help you in the closure case because what's being captured is the actual variable reference itself. How that variable reference gets used in an encompassing expression has no bearing on the capture, so it would actually be weird (from an internal consistency standpoint) to have parenthesis somehow "uncapture" the l-value within it. It also raises the question of what (x + y) would do -- would that uncapture both x and y?

All that being said, I don't totally disagree with the idea of having an explicit way of switching between the capture semantics, although I might argue the default should be to just capture r-values and then have an opt-in way for capturing l-values (i.e. a ByRef modifier rather than a ByVal modifier). Still, that's adding another layer of complexity, so I can't really say that we'll do something here, but it's definitely something we'll talk about...

re: closures continued.. ByRef, ByVal and ()

Jonathan Allen — Mon, 10 Apr 2006 03:59:06 GMT

That syntax looks pretty clean to me, and is a heck of a lot better than what we have now.