Category Archives: Visual Basic

Lambda expression improvements

WARNING: This is a speculative post. Caveat emptor.

I haven’t finished reading through all the comments from my previous post yet, but I did think it was worth stating that we are considering improvements to lambda expressions in the next version. Specifically, we’re looking at allowing single-line lambdas that don’t actually return anything, something like:

Dim x = Sub() Console.WriteLine(10)

This was something we wanted to support in 2008, but just ran out of time for. We’re also thinking about multi-line lambdas that contain statements instead of just a single expression. So something along the lines of:

Dim y = Function(x)
            If x > 0 Then
                Return x
            Else
                Return -x
            End If
        End Function

Like C#, we’d infer the return type of a multi-line lambda by attempting to pick the best type of all the Return statements.

This is really a common request, so it’s definitely something we’re strongly considering.

A little update on VB10 thinking…

WARNING: This is a speculative post. Caveat emptor.

It’s been a while since I’ve had much of anything to say about our thinking about VB10 (well, it’s been a while since I’ve had much of anything to say) and I wanted to give a quick update on our thinking:

We also keep getting asked about:

  • Iterators. This is definitely on our radar but it’s a big item. We’re considering it, but it hasn’t been thought about nearly as much as some of the other things above…

Another thing that is on our radar:

And, of course, other stuff that will be talked about in good time…

Collection initializer expressions, redux

WARNING: This is a speculative post. Caveat emptor.

When we last left collection initializers, we were discussing default types for collection initializers. Since then we’ve thought further about the feature and are considering changing the design. The problem is that as nice as type inference is, as we started to dig into what that practically meant it started to become more and more difficult to figure out what a particular collection initializer might mean. Because the meaning of the initializer in the original design depends on the context, it’s meaning could change dramatically in different contexts. Of particular difficulty was figuring out just how a collection initializer would participate in generic method type inference (i.e. inferring the type arguments to a generic method)–an important topic given how much generic methods are used in LINQ.

Without going into too much detail, what we’re considering is significantly simplifying the design. Instead of inferring the meaning of a collection initializer from context, a standalone collection initializer will always infer an array type. So {1, 2, 3, 4} will always be a single dimensional array of Integer. If you want to initialize a collection type, you use an initializer similar to object member initializers (the initializer that uses “With”). For example:

Dim x = New List(Of Integer)() From { 1, 2, 3, 4 }

The use of the “From” keyword is provisional. It may be the right keyword, it might not, we’ll have to think further on that one. However, you get the idea. The downside of the new design is that it’s more typing in the situation where you were initializing a collection in a context like argument passing (although in the case of List, you could also say {1, 2, 3, 4}.ToList()) where you weren’t going to say the type at all. The upside is that it removes significant ambiguity–when you see “Foo({1, 2, 3, 4})” you know what you’re passing and in the case of generic methods, you aren’t going to get surprising results. This also makes the feature work more like the way C#’s anonymous arrays and collection initializers work, for those of you who care about that kind of thing.

Comments?

Reserved words: what are they good for? (Absolutely nothing?)

Random musing for the day: I was thinking about reserved words in programming languages and whether they’re really necessary at a lexical level. As you know, most programming languages define in their lexical grammar a set of words that cannot be used anywhere in the language except when explicitly specified in the grammar. For example, VB reserves the word “Object”. So you can’t just say:

    ' Error: Keyword is not valid as an identifier.
    Sub Object()
    End Sub

Many languages (such as VB) allow you to work around this by providing some sort of lexical escape that suppresses the reserved nature of the word. So you can say in VB:

    Sub [Object]()
    End Sub

Confusingly, many keywords that we’ve been adding to VB lately haven’t been reserved words, to reduce the need to modify people’s code when they upgrade. Instead, they’ve been contextual keywords, that is to say they’re only reserved in certain syntatic contexts. For example, From is not a reserved word in VB in the lexical grammar, but if you start an expression with From and then follow it with an identifier, we say “Oh, yes, you’re starting a query…” For example:

    Dim From As Integer = 10
    ' OK: Unambiguously the local variable
    Dim x = From + 10
    ' OK: Unambiguously a query
    Dim y = From a In New Integer() {1, 2, 3, 4}

Which leads me to wonder: why bother with lexically reserved words at all? Why not just make all of your keywords contextual? When I started on VB, I guess I just accepted the practice since that’s what the language did before I showed up, but now I’m not so sure. Maybe there’s some blindingly obvious reason that I’m not seeing (probably there is). I can think of some historical reasons why keywords weren’t all contextual:

  1. Maybe it simplified writing a parser in “the old days,” or it simplified building a parser generator.
  2. Maybe it was because people were writing code in editors that didn’t have syntax coloring. “int int = 5; int = (int)int * (int)int / (int)int” looks pretty nonsensical if you don’t have nice coloring to tell you which are the keywords and which aren’t.
  3. Maybe there were grammatical problems with doing it? The previous example makes me wonder about whether C could handle it; I’m not an expert on how the C grammar handles the cast operator.

Anyway, it’s not extremely relevant at the moment–we’re not going to just start unreserving all the keywords in VB–but just something interesting to think about…

Collection initializer expressions

WARNING: This is a speculative post. Caveat emptor.

Well, I appear to be on a rhythm of about once a month posts, which seems OK for the moment. Moving on to another “future” topic, one of the most annoying things that we cut (at least, from my perspective) from VB 2008 was collection initializers. Collection initializers were a little different than the corresponding C# feature, because our plan was to introduce stand-alone initializers that didn’t have any intrinsic type. Instead the initializers “snap to” a particular type when they’re converted to it, just like lambdas and AddressOf expressions. For example:

' This works since VB 7.0!
Dim a() As Integer = {1, 2, 3, 4}
' This now creates a list.
Dim b() As List(Of Integer) = {1, 2, 3, 4}
' This assigns a new list to b.
b = {5, 6, 7, 8}

' If M takes Integer(), that's what it'll get. If it takes List(Of Integer), that's what it'll get.
M({1, 2, 3, 4, 5})

This is kind of nice, in that you can initialize collection types and arrays without having to state a type at all. We do the same trick C# does about looking for an Add method on a object that implements IEnumerable, so you can also use this syntax to initialize dictionaries:

Dim d As Dictionary(Of Integer, String) = {{1, "One"}, {2, "Two"}, {3, "Three"}}

All this is pretty straightforward, but there is some discussion about what type you should get if there is an absence of a target type. For example, assuming that local type inference is on, what should the following be typed as?

Dim x = {1, 2, 3, 4}

Our initial thought was that we should just infer the dominant type of the initializer and then create an array of that type. So the above example would type x as Integer(). And then the following:

Dim y = {{1, 2}, {3, 4}, {5, 6}}

Would infer a type of Integer(,), a two-dimensional array of Integer. With more nesting, you’d get more dimensional arrays. However, as we talked about it more, it seemed like maybe it might be more useful to infer List(Of T) for the 1-dimensional initalizer, Dictionary(Of K, V) for the 2-dimensional initializer, and nothing for more dimensions. So the type of x would instead be List(Of Integer) and the type of y would be Dictionary(Of Integer, Integer).

Both seem reasonable, so I’m curious what people would think. Remember, we will only fill in a type if we’re in a context (like type inference) where there’s no target type to use. We’ll always use a target type if there is one.

Implicitly implemented interfaces

WARNING: This is a speculative post. Caveat emptor.

This one is a little more speculative than the others, but it’s something that we’d like to get some feedback on. One complaint that we get from time to time has to do with interface implementation. A lot of people like the fact that there’s a nice explicit interface implementation syntax in VB, but sometimes it starts to feel, well, a little verbose. Even if you let the IDE create all the interface implementations for you, there’s still a lot of extra characters with all those “Implements IFoo.Bar”s, especially when the implementing method is the same name as the interface method.

One idea we’ve been kicking around is relaxing our rules to allow for implicit interface implementation. Today, when we’re checking interface implementation for some interface I1 what we do is:

  • Check to see if any base classes implement any of the members of I1. If so, we mark those methods as implemented.
  • Check to see if the current class implements any of the members of I1. If so, we mark those methods as implemented. If the current class implements a method that a base class implemented, the current class replaces that implementation.
  • If all of the methods of I1 are not implemented, we give an error.

What we would do is slightly modify the rules to:

  • Check to see if any base classes implement any of the members of I1. If so, we mark those methods as implemented.
  • Check to see if the current class implements any of the members of I1. If so, we mark those methods as implemented. If the current class implements a method that a base class implemented, the current class replaces that implementation.
  • If there are any methods of I1 that are not implemented, we check to see if there is a method with the same name and signature in the current class, and if there is, then that method implements the interface method.
  • If all of the methods of I1 are not implemented, we give an error.

What this would mean is that you could do something like this:

Class C1
    Implements IComparable(Of Integer)

    Public Function CompareTo(ByVal other As Integer) As Integer

    End Function
End Class

And not get any errors. There are a couple of things to note here if you’re familiar with C#, though. First, unlike in C#, if you declare a method in a derived class that has the same name as an interface method that is declared in a base class, you will still have to explicitly implement the interface method if you want the derived class method to take over. For example:

Class Derived
    Inherits Base
    Implements IComparable(Of Integer)

    ' Will not take over IComparable(Of Integer).CompareTo since Base already implements it!
    Public Function CompareTo(ByVal other As Integer) As Integer

    End Function
End Class

One could argue whether the derived class should or shouldn’t take over the implementation, but the bottom line is that if we allowed this we would be opening a potentially serious backwards compatibility problem. The above code could be written today (assuming Base implements IComparable(Of Integer)), and CompareTo will not take over the implementation of the interface. If recompiling your application in some future version of VB switched the implementation, this could introduce a very subtle and possibly very bad bug into your program. So it’s really a non-starter.

The other difference from C# is that we won’t search base classes for implicit interface implementations. For example, the following code would still give you an error:

Class Base
    Public Function CompareTo(ByVal other As Integer) As Integer

    End Function
End Class

Class Derived
    Inherits Base
    ' Error: IComparable(Of Integer).CompareTo is not implemented!
    Implements IComparable(Of Integer)
End Class

This can also be debated, but in the end we tend to err on the side of being more conservative-since Base didn’t implement IComparable(Of Integer) itself, it seems odd to pick it up when implementing the interface, as we have no way of knowing for sure that it’s really appropriate. There are also other highly technical issues relating to the mechanics of interface implementation that would make this situation complicated, especially if Base was in another assembly that we had no control over.

So the question is: would people find this useful? Annoying?