Hey Mike,

Thanks for taking the time to reach out. I’m curious from your example why you’d use the lambda syntax at all in this case. It’s important to note that once you introduce a single .Where call it’s always shorter to have written a query:

Dim smiths = db.People.Where(Function(p) p.LastName = “Smith”)

’ Remember the final Select in VB is optional unless you’re selecting something other than the range variable(s) in scope.
Dim smiths = From p In db.People Where p.LastName = “Smith”

And yes, this effect compounds over time with each additional call

Dim birthdays = db.People.Where(Function(p) p.LastName = “Smith”).Select(Function(p) p.Mother).Select(Function(p) p.BirthDate)

’ All valid
Dim birthdays = From p In db.People Where p.LastName = “Smith” Select p.Mother Select Mother.BirthDate
Dim birthdays = From p In db.People Where p.LastName = “Smith” Select p = p.Mother Select p.BirthDate
Dim birthdays = From p In db.People Where p.LastName = “Smith” Select p.Mother.BirthDate

The VB LINQ experience is really built around query comprehensions. One should start from a position of using query comprehensions and only not use the keywords when there’s a good reason, by design. That’s one reason VB has several more query operators than C# does – Skip, Skip While, Take, Take While, Group Join, Aggregate, and Distinct, to extend the usefulness of the pattern. By contrast the C# comprehensions add so little savings that many users never use them.

As for the choice of lambdas in general both VB and C# use syntax for their anonymous methods that very closely resembles what they use for named methods:

C#:

void Main(string[] args) {}

(args) => {}

VB:

Sub ()

End Sub

Sub ()

Sub ()

End Sub

Function [As ]

End Function

Function ()

Function () [As ]

End Function

In both cases, the syntax wasn’t chosen arbitrarily but to be consistent with the rest of the language. For the most type they both just drop the name and return type (C# actually needs the arrow for IntelliSense and because (x) x is ambiguous). Lambdas are just inline nameless method declarations so they look exactly like inline nameless method declarations. The different lambda syntax in the two languages is just an artifact of their individual natures. For instance, in VB Functions and Subs are distinct kinds of methods and they have corresponding distinct kinds of lambdas – this is pretty important because in VB ‘=’ means either assignment or comparison depending on whether it’s in the context of a statement or an expression:

’ Assignment
x = y

’ Comparison
If x = y Then Return

That the distinction between subs and functions is carried over into lambdas is what makes it possible to distinguish these cases:

Control.Invoke(Sub() TextBox1.Text = result) ’ Assignment.

and

AddHandler Command1.CheckEnabled, Function() TextBox1.Text = result ’ Comparison.

If we used the C# syntax it would be ambiguous (ask me some day about how you tell the difference between a void-returning and a task-returning async lambda in C#).

It is worth noting that if you’re finding the inline syntax to be a bit distracting from the surrounding context you can always extract the lambdas to locals and give them names for easier reading at their use site. VB can magic up special delegate types so that you don’t have to type much more.

Dim isASmith = Function(p As Person) p.LastName = “Smith”

Dim mothersDob = Function(p As Person) p.Mother.Birthday

Dim birthdays = db.People.Where(isASmith).Select(mothersDob)

Though I find it more helpful to extract lambdas the more complicated they get – especially if they become multiline, it can help sometimes if you have a lot of small ones to create a sort of “setup, execute” flow.

Anyway, while I know there are cases where this can get a little crazy that’s just how things shook out. If you’re interested in a little history take a peek at this thread where the community debated it for some time:

http://www.panopticoncentral.net/2006/12/08/lambda-expressions-part-i-syntax/

I’ll spoil the results and let you know that the current syntax was the OVERWHELMING community favorite, and I’ve no regrets.

Here’s a great list of different syntaxes for lambdas in the various languages. As you can see VB’s more in the camp of Python, Ruby, JavaScript, F#, and Delphi with regard to syntax for lambdas. It’s important to recognize that every language does it different for reasons and that while VB is very different from C# in this case it’s not so different from many other languages.

http://en.wikipedia.org/wiki/Anonymous_function#Examples

I think we’re highly unlikely to reverse course on this issue (but who knows) since doing it would add a lot of conceptual weight to the language with constrained benefit and we honestly haven’t seen a more concise syntax that really felt great for VB, certainly not moreso that what we have today. It wouldn’t be fair to hold your votes on the off chance that some day someone slips in the shower, hits their head and comes up with one so I’m going to close this suggestion and return your votes to you to use on other suggestions.

Regards,

-Anthony D. Green, Program Manager, Visual Basic & C# Languages Team

Hey pm,

Thanks for the suggestion. The thing about VB is that keywords are generally preferred from a language design standpoint to cryptic symbols and implication. functionname really doesn't convey much to the reader unless they're already very familiar with the VB syntax. I'm not saying AddressOf is wildly better but it does make a better jumping off point for doing a reference search or discussing the right terms with other developers (you can ask a chatroom or forum about AddressOf or bing "AddressOf" and get help - it's much harder to search for "". Combined with the fact that it’s been in the language since VB5 (so 6+ releases now) it feels like something that’s pretty baked. While I’m not saying we’d never add a new syntax to the language purely for the sake of brevity or cosmetics there are certainly higher priority and more common statements and expressions who need that love and care more than AddressOf.

As we’re not likely to do this in the future I’m closing this suggestion and returning your vote to you to use on other suggestions.

Regards,

Anthony D. Green, Program Manager, Visual Basic & C# Languages Team

Hey Justin,

Thanks for the suggestion. I can understand how horizontal screen estate is at a premium. In your example you used two nested namespace declarations but in both VB and C# you can combine these into a single namespace block:

Namespace Foo.Bar

End Namespace

This still adds a single level of indentation but that’s a lot better than 2 or more. In C# this is the standard level of indentation by default but in VB most classes don’t require a namespace declaration by default due to the project-level Root namespace property. Given that namespace declarations are already pretty well-understood and the marginal benefit saving a few whitespace characters would grant for the tradeoff of adding another mechanism to the language we’re going to decline this suggestion and return your vote back to you to use for other suggestions.

Regards,

Anthony D. Green, Program Manager, Visual Basic & C# Languages Team

Klaus,

As others have mentioned VB is very intentionally not a case-sensitive language. In some ways that’s one of its strengths and inline with its design philosophy. Though there may be conventions on when to choose what case, as there are in English, also like English the casing of a word doesn’t create a completely independent entity or concept, by design. That insensitivity is easier for new programmers, more productive for intermediate and advanced developers, and allows for a far more forgiving IntelliSense experience. In all my time using the both languages I’ve never seen a situation where case-sensitivity would be of any benefit. Even when looking at C# the most common usage is differentiating properties from their backing fields and in VB the _ prefix is far more common, especially now that this convention is enshrined via auto-props. It would add a tremendous amount of complexity and virtually nonexistent benefit.

Because I honestly feel that there is absolutely no chance that VB will ever introduce case-sensitivity, even through an Option statement, I’m going to close this suggestion to free up your votes to put toward other suggestions.

Regards,

Anthony D. Green, Program Manager, Visual Basic & C# Languages Team