Share via

A wish-list for future versions of VB

  • Article

Visual Studio 2010 is almost out the door. Now is a good time to look at further features we want to consider for future releases.

Our job as language-designers is to make the language better for its users. Sometimes, like with LINQ and lambdas in VS2008, we start from our anticipation of industry trends and then lead with our own vision of how things ought to be done better. And sometimes we respond more directly to user suggestions, sometimes using the designs they suggest.

 

The wish-list

We have an outstanding wish-list of 80+ ideas that came from us ourselves, from the groups within Microsoft who build on top of VB, from the blogs of "Most Valued Professionals" (MVPs) like Bill McCarthy and Đonny and from many other users.

Req0: Don't add to (or change) the language
Core1: Iterators
Core2: Inline and multi-line comments
Core3: Dynamic pseudo-type (scoped late binding)
Core4: Flexibility with implementing properties
Core5: Overloading on optional parameters
Core6: "VB-Core"
Core7: Unify late-binder with early-binder
Core8: Attribute targets
Core9: Readonly auto-properties
Core10: Namespace Global
Core11: An "XML pattern"

Power1: REPL and "vbscript.net"
Power2: Async and resumable methods
Power3: Shared methods inside interfaces
Power4: Custom property and event templates
Power5: Custom anonymous types
Power6: __CALLER_MEMBER__
Power7: Dictionary and list literals
Power10: Reduce verbosity through #light
Power11: Extension properties

Req1: Put the loop control variable inside the For loop
Req2: Null-propagating field access
Req3: Multiline strings
Req5: Unsafe and pointer support
Req6: better casting
Req7: Separate syntax for assignment := and comparison ==
Req8: Use [ ] for arrays
Req9: Allow CObj in constants and attributes
Req10: Shared variables in method bodies
Req11: International date literals
Req12: Select Cast on object identity and type
Req13: Catches in using blocks
Req14: Non-empty default partial methods
Req15: GetType for instances, methods, properties
Req16: Modules that don't auto-import their contents
Req17: Extension classes
Req19: Allow statements to start with parentheses
Req20: Range expressions
Req21: Allow unambiguous types from ambiguous namespaces
... AND ANOTHER 40+ TO COME!

 

Please give feedback

Over the coming month I'll blog about every item on the wish-list along with our evaluation of it. We have our own ideas about what are the priorities for the VB language. You'll have your own ideas - please tell us.

  • We want to hear feedback from everyone!
  • Write with scenarios that you think are awkward to code at the moment, even if you don't have ideas on how to fix them: it's good for us to know what "pain points" in the language are encountered most frequently by users.
  • If you have specific ideas for changes to the VB language, write in with those too.
  • If you think that other people's ideas are good, please write to say so. If you encounter their problem-scenarios frequently, please say so.
  • SCENARIOS ARE KING. If there's an idea that you'd like us to prioritize, the very best way to bolster its chances is with a scenario that you've faced where the idea would have helped.

The best way to give feedback is through comments on this blog so that other people can read and respond, or directly by email to me lwischik@microsoft.com.

 

Practicalities

We can't do everything. Sometimes we can't even do anything. Two of the Erics on the C# language team have explained how we make our decisions.

Eric Gunnerson's " Minus 100 Points " . Complexity itself has a cost: therefore only add new language features if their benefits outweigh this cost.

Eric Lippert's " Why doesn't the language do X? " Every language feature requires design, specification, implementation, testing and documentation: therefore only allocate our resources on the features that bring the most benefit.

Comments

  • Anonymous
    January 28, 2010
    One idea I've liked ever since Paul Vick posted about it was the option of lower-cased keywords: http://www.panopticoncentral.net/archive/2007/07/20/21212.aspx I think the language would be more readable with fewer "Screaming Initial Caps".  It seems like a fairly simple change, given that Paul said he was able to create "a bootleg of the compiler" to do it. (Obviously on a team there could be source-control hassle if one person's compiler makes the keywords all lower-case, and another's re-upper-cases them.  But it's just another matter of coding style for the team to agree on.  And can't every source control system be set to ignore case anyway?) How about it?

  • Anonymous
    January 29, 2010
    An idea for the VB compiler would be to provide some option that would show all compiler warnings, instead of capping the list at 100.   Currently, there is no way for us to estimate the effort that would be involved in fixing all of the warnings in our legacy code base.

  • Anonymous
    January 29, 2010
    Yeah, the <=100 warnings/errors annoyed me when I was porting VB6 projects, no way to know how much work was left.

  • Anonymous
    January 29, 2010
    Hey, when I click on Core5 FireFox shows me Core 6

  • Anonymous
    February 01, 2010
    C# yeild statement analogy in VB! Otherwise making lazy stuff work takes a lot of work :)

  • Anonymous
    February 11, 2010
    When will we be able to get rid of byval in all of our methods?

  • Anonymous
    February 12, 2010
    What Rob said, seconded.  By now I think it's safe to say that we all know that ByVal is the default, and it's easier to see the few cases of ByRef if we don't have all those ByVals cluttering up the screen.  Can you ditch them?

  • Anonymous
    February 25, 2010
    I second Ivan. Generators are useful. Not necessarily with Yield, exactly like in C#. It may well be more interesting and fitting into VB to explore some other approaches to coroutines, as long as they aren't less expressive.

  • Anonymous
    March 02, 2010
    A C# <--> VB converter as SharpDevelop does, both for a file and for a whole project.

  • Anonymous
    March 02, 2010
    The comment has been removed

  • Anonymous
    May 13, 2010
    Something that seems to be missing here are two suggestions from Bill McCarthy, namely "NameOf" (similar to TypeOf, but returns a string instead of a type) &/or the ability to use an attribute like "<RaisesNotifyPropertyChanged>" on a property, either of which would help ENORMOUSLY in the implementing of INotifyPropertyChanged which has to be hand-coded AGAIN & AGAIN & AGAIN. The compiler could help out here as it has with many other tedious things, like auto properties & anaonymous types etc.

  • Anonymous
    October 31, 2010
    In next ver of VB pl enhance "OR" oprator to cut short on CODE. For example Public Function IsCharIsVowel(ByVal C as Char) as Boolean   If C = "A" or C="E" or C="I" or C="O" or C="U" Then      Return True   Else      Return False   End if End Function 'Suggestion to Improve to this syntax Public Function IsCharIsVowel(ByVal C as Char) as Boolean   If C IN ( "A" ,"E" ,"I" ,"O" ,"U") Then      Return True   Else      Return False   End if End Function

  • Anonymous
    December 06, 2010
    Function IsVowel(ByVal C As String) As Boolean    Return "AEIOU".Contains(C) End Function Function IsVowel(ByVal C As String) As Boolean    Select Case C        Case "A","E","I","O","U"            Return True        Case Else            Return False    End Select End Function