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.