Roslyn: VB Local Functions

[AdamSpeight2008]

Is there a branch with Local Function feature in vb.net?

[jmarolf]

VB's lambdas already have most of the value that local functions brings (iterators, immediately invocable, etc.) as such the VB design team didn't feel they should be pigeon-holed into this release. @AnthonyDGreen can add more context here, but I feel this is an excellent example where parity\co-evolution would not serve the language very well.

C# lambdas are very limited compared to VB's, hence the need for local functions. VB lambdas do enough that the development effort should (in the design teams opinion) be used for other VB features.

[AdamSpeight2008]

@jmarolf I see VB's lambdas as local delegate functions. Not as local functions.`

[AnthonyDGreen]

In both languages we looked at two approaches. Local functions and improving lambdas. For improving lambdas that would mean optimizing away delegate allocations when a lambda is only used locally, etc. What we concluded for C# was that in order for that approach to be valid we'd have to add all the things VB has to lambdas that C# doesn't: anonymous delegates, iterator lambdas, etc. That seemed like a lot to add to C#. Conversely, since VB already had a lot of groundwork it made more sense to keep going in this direction than invent yet another way to accomplish this. The VB compiler already optimizes away anonymous delegates if they're only realized transiently and then converted to a nominal delegate type. It seems like an easy next step to elide delegates entirely.

It's less about exposing a particular syntax in the language as exposing certain capabilities.

Another concern I have, particularly with the local function syntax if we took what we did in C# and applied it directly to VB is that it would break Visual Basic's error recovery a lot. One thing I take pride in about Visual Basic is that if you make a syntax error the impact is usually limited to the containing statement or block because we recover when we encounter something that starts a new block. We've weakened this already with multi-line string literals and interpolated string, and XML literals, sadly. I don't want to make it worse. For example:

``` VB.NET
Sub FirstMethod()
' I haven't typed the End Sub or accidentally deleted it.

Sub NextMethod()

End Sub
```

The parser knows when it encounters the Sub NextMethod() statement that FirstMethod was never closed and so it closes it and reports and error instead of consuming the next statement. If we have local functions then that doesn't work. The parser will then greedily consume the remaining Subs and Functions in the class as local functions of FirstMethod. Then the formatter will indent all of those methods as nested within FirstMethod. I can imagine this more likely happening while typing a new local function than a top-level method but it worries me. We could come up with a more elaborate syntax to differentiate local functions from normal functions. But again, that's a lot of design work to avoid just optimizing the performance of what we already have.

Take a look at this tweet I put out a bit ago: https://twitter.com/ThatVBGuy/status/755549102910218240

That's how I use VB lambdas today. Would local functions add much over that?

[AdamSpeight2008]

@AnthonyDGreen what about prefix-ing the lamba with an attribute <local> to elide delegates entirely,

Dim printSpace = <local> function( value as BoardState)
             select case value
             case BoardState.Blank
                 return " "
             case BoardState.X
                 return "X"
             case BoardState.O
                 return "O"
                 end select
          end funtion

[jmarolf]

@AdamSpeight2008 I believe what @AnthonyDGreen was suggesting is that the VB compiler would elide delegates automatically if the lambda/sub is never passed outside of the function. There should be no need for a prefix.

[xieguigang]

C# language using => operator for a lambda, probably VB.NET can using <= operator for a local function

Here is an example