A wish-list for future versions of VB


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 (13)

  1. Kyralessa says:

    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?

  2. Tom says:

    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.

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

  4. Dzonny says:

    Hey, when I click on Core5 FireFox shows me Core 6

  5. Ivan says:

    C# yeild statement analogy in VB! Otherwise making lazy stuff work takes a lot of work :)

  6. Rob says:

    When will we be able to get rid of byval in all of our methods?

  7. Kyralessa says:

    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?

  8. Krzysztof Maczyński says:

    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.

  9. dominique says:

    A C# <–> VB converter as SharpDevelop does, both for a file and for a whole project.

  10. dominique says:

    Improve the debugger :

    – on big projects, the step by step in debug mode is slow .. slow

    – add Watchpoints as they exist in PDS Basic 7.1 (enter expression which will break when True)

    For example, myValue = 10 and when myvalue=10 in any place, the code stops and starts in debug mode. You don’t need to put breakpoint on a specific line, you put the watchpoint for the whole code.

    – in debug mode in step by step, we can’t see the output display (the form with the controls). Allways in PDS 7.1, it was possible with F4.

  11. yannduran says:

    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.

  12. Hitesh says:

    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

  13. MrG says:

    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