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.
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 languageCore1: IteratorsCore2: Inline and multi-line commentsCore3: Dynamic pseudo-type (scoped late binding)Core4: Flexibility with implementing propertiesCore5: Overloading on optional parametersCore6: "VB-Core"Core7: Unify late-binder with early-binderCore8: Attribute targetsCore9: Readonly auto-propertiesCore10: Namespace GlobalCore11: An "XML pattern"
Power1: REPL and "vbscript.net"Power2: Async and resumable methodsPower3: Shared methods inside interfacesPower4: Custom property and event templatesPower5: Custom anonymous typesPower6: __CALLER_MEMBER__Power7: Dictionary and list literalsPower10: Reduce verbosity through #lightPower11: Extension properties
Req1: Put the loop control variable inside the For loopReq2: Null-propagating field accessReq3: Multiline stringsReq5: Unsafe and pointer supportReq6: better castingReq7: Separate syntax for assignment := and comparison ==Req8: Use [ ] for arraysReq9: Allow CObj in constants and attributesReq10: Shared variables in method bodiesReq11: International date literalsReq12: Select Cast on object identity and typeReq13: Catches in using blocksReq14: Non-empty default partial methodsReq15: GetType for instances, methods, propertiesReq16: Modules that don't auto-import their contentsReq17: Extension classesReq19: Allow statements to start with parenthesesReq20: Range expressionsReq21: 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.
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 firstname.lastname@example.org.
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.