I suggest you ...

Make the Optional keyword optional

Please allow

Private Sub Test(s As String = 1)

as in C# besides the current version:

Private Sub Test(Optional s As String = 1)

This removes redundancies (--> improves readability, accelerates writing code) and drives forward the co-evolution of VB/C#. I don't see any reason not to allow this.

147 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Julius Kunze shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Julius Kunze commented  ·   ·  Flag as inappropriate

    And there it appears, the "Basic" of Visual Basic. ;) Didn't believe that this philosophy is still guiding through some big decisions.

    Seriously, thank you for this detailed answer! Now I understand your decision of making the optional keyword optional a lot better.

    --> Time for me to switch to C#. ^^ Just kidding, I need VB-IntelliSense kindly popping up and helping you even when you are relaxing on your couch while your computer is off. :D

    Julius Kunze

  • Anthony D. Green [MSFT] commented  ·   ·  Flag as inappropriate

    Hey all,

    I've thought about things like this and here are some of my thoughts on the matter.

    More often than not when I use optional parameters in VB the default value I'm using is a null value:

    Optional s As String = Nothing,
    Optional formatter as IFormatProvider = Nothing

    So, we have two cases: places where getting rid of the modifier would clean up code and places where cleaning up the default value expression would clean up code. How to choose? We could maybe require one or the other but not both?

    That's the first thorny issue. The second is that it's wholly against the spirit of the VB language to let the optionality of the parameter be inferred from a default value expression. C# stylistically prefers a terse syntax where if you remember the right sequence of symbols to attach to something can drastically alter its meaning:

    In C# the difference between declaring a field and a property is knowing to use the curly braces after the name {}.
    In VB there's the Property keyword.

    In C# a method that doesn't return a value is designated by a special return type 'void'.
    In VB there's the Sub keyword.

    In C# an iterator method is one that happens to include 'yield return' statements.
    In VB it's a method declared with the Iterator keyword.

    There are several reasons for this pattern in VB:
    1) Keywords tell you what to call things. If you don't have a keyword you won't know what to call it. If you don't know what to call it it's harder to look up help about it on the internet. Imagine some newer developer trying to bing "parameters with equals on them". Names matter.
    2) Keywords give you a great places to put your cursor and hit F1 to jump to the help topic, or hover over for context help. This makes it easier to learn the language. I learned QuickBasic (many years ago) almost entirely this way.
    3) Keywords often make for better IDE experiences because the IDE knows what help to provide based on what keywords have been typed so far.
    4) Keywords make features of the language more discoverable. If you're unfamiliar with the language and you begin to declare a parameter the IntelliSense suggests the modifiers you could use (ByVal, ByRef, ParamArray, and Optional) letting you know that such things exist.

    Not all of these things necessarily apply all the time but philosophically it's just a way the languages are different. Co-evolution is in no way an effort to make the languages the same but to respect the strengths and styles of each while enabling developers in either to take full advantage of the power and flexibility of Visual Studio and the .NET ecosystem. VB's never going to be as terse as C# and it's not really a goal for it to be. Each language just tries to be itself to the max it can so customers with particular styles gravitate toward the one that resonates most with them.

    This is a little different from the ByVal change because ByVal was already optional (it's the default). We'd been inserting it because in VB6 ByRef was the default and that was changed in .NET so we needed to keep reminding people that the language had changed. After 8 years we figure people got the point so we just fixed the IDE to stop automatically inserting it. The Optional keyword is actually required (ironically).

    It is, however, completely consistent with the language if the default values of optional parameters are the default values of the types of the parameters because that's what 'default' means. Every variable of a type has a default value (Nothing) if not otherwise set. It's wholly redundant to say that "if omitted the default value of this parameter will be the default value".

    Anyway, that's my current thinking on it.


    -Anthony D. Green, Program Manager, Visual Basic & C# Languages Team

  • Julius Kunze commented  ·   ·  Flag as inappropriate

    Dear developer team, you already did great work with making the ByVal-qualifier optional. We need exactly the same work here!

Feedback and Knowledge Base