A look at Visual Basic 11
Visual Basic 11 brings with it several new features including asynchronous functions and the long awaited iterators.
The asynchronous support in Visual Basic was built in conjunction with C#’s version and they share the same design and keywords, namely Async and Await. Underpinning these keywords is the Task Parallel Library, which was introduced in .NET 4.0
In theory asynchronous functions can be used anywhere, but their main purpose is to prevent blocking on sensitive threads. For example, you can use it when invoking a file operation, service call, or database request from the UI thread of a WPF or Silverlight application. When the operation completes it will be automatically marshalled back to the UI thread, but without blocking it in the meantime.
Another example of sensitive threads are those in the thread pool used by ASP.NET. Normally ASP.NET will limit the number of concurrent threads to prevent performance degradation from excessive context switching. This is usually set to an arbitrary base number, which is increased if the runtime detects a lot of blocking. But if asynchronous, non-blocking calls are used instead then the system can run closer to the ideal one thread-per-core model.
Visual Basic 11 will support both iterator functions and iterator blocks. An iterator function works like C#’s iterators, with a slight syntactical change. In VB you must declare the function as “Iterator Function” instead of the normal “Function” keyword. When returning values, VB developers use “Yield [expression]” instead of C#’s “yield return [expression]”.
Anthony Green expands on this point,
While the Iterator keyword definitely allowed us to avoid the problem you mention of introducing a breaking change to existing source bases which use Yield as an identifier (e.g. financial applications) and to keep a concise keyword like Yield instead of a keyword pair such as Yield Return that wasn't the only reason. VB, in general has a declarative style to it (XML literals, Handles, Implements); we felt that it was important in VB that if a function was an iterator that the code simply state that. Similarly if people were going to call them Iterator and Async Functions then the code should as well. You can see this pattern in other VB modifiers such as ReadOnly and WriteOnly properties - we could infer that the Setter was missing but semantically that means ReadOnly so the property is declared ReadOnly.
Another benefit to the explicit declarative modifier is that we can give a better editor experience. In VB when you type "Iterator Function F As Integer" the IDE will automatically insert the "IEnumerable(Of Integer)" for you. Similarly if you type "Async Function F As Integer" the IDE will replace the "As Integer" with "As Task(Of Integer)" so that you don't have to. Again, parallels can be drawn with Properties where the presence of the ReadOnly modifier allows us to auto-generate better code for you.
An interesting twist is support for iterator blocks, a type of lambda expression. The example below shows a simple lambda expression that builds an IEnumerable of Integers and then iterates over it. Iterator blocks can also be used within XML literals by appending “.Invoke()” to the “End Function” line.
Like C#, Visual Basic will also support the CallerMemberName, CallerLineNumber, and CallerFilePath attributes. When applied to optional parameters the compiler will automatically insert the correct values. Logging and notify property changed events are the two most cited uses for these attributes.
Other improvements include:
- Namespace Global, which is used for code generation scenarios.
- Optional parameters in overloaded methods, to support some backwards compatibility scenarios.
- Elimination of the ByVal keyword in method signatures. Visual Basic’s IDE started automatically adding this keyword in version 7 when the default was changed from by-reference to by-value.