Of programming languages, VB has in many ways had a checkered history mainly due to the changes from VB6 to VB7 (VB.NET). I remember clearly the change from “Wend” to “End While”.  Some folks claimed that was “gratuitous”.  To me, I couldn’t see what the big deal was about… the IDE would fix it if I typed Wend, and the language itself was clearer/more consistent. I think that’s the real problem with deprecation, not the fact that changes might actually be good, but more so some folks will make lots of noise about any change that is made.  Paul ventures into this territory again… perhaps now folks that are using VB (.NET) are over the VB6 to 7 round of changes 😉

Looking at Paul’s list :

• Type characters.  I never use them and can only remember $ for string.  It’d be nice if you could type Dim s$ and have the IDE auto-magically spell that out as Dim s As String  🙂
• Copying of boxed value types.  That’s a big can of worms.  At present VB attempts to make value types behave as value types when boxed. I’d say leave well enough alone unless there are specific reasons to change this. That time evaluating and making the change might be better used elsewhere 😉
• Mid$ assignment. How will this impact on upgrading code ? I think it’s actually deceptive given the way strings work in .NET is different from the Ole strings, so a truer upgrade would be to change the code to an assignment, e.g  s = Mid(s, 2, 3, “abc”), or even better a Replace overload on String, such as s = s.Replace(2,3,”abc”).  Unfortunately there is no Replace method on String that provides that functionality.  Until there is, I’d leave this one alone too.
• End statement.  Well I used this just the other week.  It was in an upcoming article I wrote on using NamedPipes to replace the issue ridden VB single instancing framework. In my case, the “My” framework was just initializing, so their was no My.Application that could be used.  I probably could have used System.Environment.Exit, but that seems like a step backwards somehow.  A quick peak in reflector shows that End also ensures that any files opened the old fashioned way are still closed.  So removing this could have upgrade issues.  I also don’t see any gain in removing it other than perhaps the impact it has on statement completion and line continuation.  If it’s removal is needed for support for line continuation without the _’s, then I’d vote for a replacement, such as VB.End or Micsosoft.VisualBasic.End
• Erase statement.  Yes it’s useless and deceiving.  The big issue is ensuring an update wizard addresses this properly, including one Vb6 to VB 10, and VB7, 7.1, 8 and 9 to 10.
• REM  I think the only person I’ve seen using them is Erik 😉  But is there much gain in removing them ?

Where I’d like to see deprecation address is Option’s.  First Option Compare Text should be completely deprecated. There’s other ways to do those comparisons and it really does add a LOT of baggage to VB’s string comparisons. Option Explicit Off is also one of the most useless error prone options a language could have. Option Strict Off does have usages, but the language should instead provide explicit ways of doing the late binding that provides,such as dynamic identifiers and dynamic operators.  With them in place Option Strict becomes obsolete.  And that leaves us with Option Infer. If these other options are removed then there is no longer a need for Option Infer.