WARNING: This is a speculative post. Caveat emptor.

I know that I’m running a great risk of touching the third rail of the VB community by even speculating about this, but it seems like the right time to have a bit of a conversation about the big “D”-word.

That is, deprecation.

Yes, deprecation. Now before anyone starts freaking out, foaming at the mouth or writing a petition, let me emphasize that my thinking along these lines is entirely within the guidelines discussed in the language specification, which mandates a long and gradual process of deprecation that involves continuing to support the deprecated feature for a reasonable period of time. The guidelines also state in part:

…feedback must be solicited from the user community on deprecation of the feature and full notice given before any final deprecation decision is made. The deprecation process may be reversed or abandoned at any point based on user community feedback.

So I’m really just floating some personal trial balloons here. After all, it’s now been almost three major releases since the big move to .NET, and I think it’s started to become clear that some of the features we carried forward are a bit, uh, underused. In the interest of paring down the language specification just a bit in it’s inevitable march towards more and more pages, I’ve been pondering the question: “If I was going to deprecate parts of the language that don’t seem to be used, what would I deprecate?” I’ve come up with a few candidates that seem pretty safe:

• Type characters. Yes, we still allow you to say “Dim a$”. So far as I have ever seen, no one uses them anymore. It would be nice to reclaim a bunch of characters at some point in the future, and it would be relatively easy to include error corrections to fix this up.
• Copying of boxed value types. I’m not even sure I could explain this in a bullet point. If you read section 8.6 of the language spec, Value Type Conversions, it’ll discuss this a little more detail. I think this is counterintuitive behavior for most people and is incomplete in any case. The only real question here is: are there programs that depend on this behavior? We’d need to think/talk a lot more about it before we could even consider this one.
• Mid$() assignment. Bet you didn’t know you could even do this, did you? See section 10.6.3 in the language spec for more on this.
• End statement. I’m curious if this one is still used by people, especially now that most frameworks like WinForms and WPF have Application objects that have a proper Exit/End method. If this one is popular, it might not fly as deprecatable.
• Erase statement. I’ve found that ReDim is actually still fairly useful as a shorthand way to redimension an array. However, Erase is completely useless–you could just replace it with an assignment to Nothing and you’d get the same thing.
• REM comments. Bet you didn’t know you could even do this one either, did you? There’s something nostalgic about it (Erik Meijer loves them), but, really, who uses them anymore?

You’ll note that I’m only including things here that I think are truly not used much or not useful. There are things I think some people would like to see disappear (like, say, On Error), but are still being used heavily enough to make them be not reasonable candidates.

I’m curious what’s people’s feelings about this are. Does this just bring up bad memories? Are there other candidates you’d throw on the list? As I said, at this point, I’m just talking. Depending on the reaction, the next step would be to look a little more formally at it in the team…

WARNING: This is a speculative post. Caveat emptor.

Last week, one of the VB MVPs asked on a private alias what our thinking was about VB10. As I kind of indicated in my previous entry, I don’t think we have a clear idea yet of what’s going to be on the table for the next rev-VB 2008 was kind of an aberration in that LINQ was in gestation long before VB 2005 even shipped. But I can say what’s at least on my mind:

• Hosting or, more generally, opening up the compiler services to the outside world.
• Decreasing lexical “noise” when looking at VB code.
• Increasing the extensibility of the language so that it takes less work to extend the language and can be done by libraries (Ruby is an example of what I’m thinking of here, but only a general example).
• Addressing UNDONE tasks from Orcas (object initializers, statement lambdas).
• Addressing persistent annoyances (line continuations is a good example here).
• Addressing whatever else comes up from the community as we release VB 2008.

I know that I’ve already added the usual caveats above, but I want to make double clear this is just what’s on my mind at the moment-in other words, things that I’m personally thinking about. These are not official team priorities, planned for the next rev, or anything like that. The next version could look radically different than the list above. I should also add that I mostly think about the language, so that’s why this list doesn’t talk about the IDE.

I’d be interested (in keeping with the last bullet point) what people might be specifically in for the next release. What’s at the top of your list these days?

Things have been pretty quiet around Panopticon Central since I did a bit of talking about “VBx” back in May. Partially this has reflected the fact that we’re at a pretty early stage of thinking about the post-VS 2008 world, so there isn’t a lot solid to talk about. Partially this has reflected the usual shifts in emphasis and strategy that occur around the end of a major product cycle as more and more people start to get freed up to think beyond what they’re delivering next month. And partially this has reflected that I’ve got two kids at home now, and that just seems to suck up some of the extra time that I used to use for blogging…

That said, I think it’s worth spending a moment catching up on what’s going on with “VBx” (at least that I can talk about in public).

I think the first thing that’s worth saying is that pretty much everyone seemed to dislike the codename “VBx,” mostly because it overlaps too much with the old VBX controls and partially because it seemed to imply that we were developing another version of the language (which we aren’t). Fair enough. For the moment, then, instead of talking about “VBx,” I’m going to talk about “VB10”. This isn’t an official codename at all, just a personal shorthand way of referring to “the next major version of Visual Basic.” Maybe it will be version 10, or maybe it won’t, but I hope it will be a little less confusing than “VBx” was, in that it should emphasize the continued unity of the VB language.

Back in May, our goal was to have something to CTP in the PDC07 timeframe, which would have been this month. But that turned out to be a more aggressive timeframe than expected. However, even if we haven’t got something solid to CTP just yet, we’ve still got some ideas of where we’re headed and what you might expect to see in VB10. So over the next few months, my goal is to write some speculative pieces on what we are thinking. The purpose would not be to make feature commitments or say what’s definitely in or out of the next version, but instead to get some of our ideas out there and see what people think, see whether there is any traction or not, and determine if we’re crazy or not.

Each entry, though, would need to come with some pretty heavy caveats. To wit:

WARNING! This is a speculative post. It reflects the individual thoughts of the author at a particular point in time. It does not necessarily reflect the future beliefs of the author, nor does it necessarily reflect the beliefs, current or future, of the team as a whole. No conclusions can or should be drawn from this article about future features, plans, or directions of the Visual Basic language. These features may show up in the product as some point, or they may not. If they do show up, they may not look or work as described here. Caveat emptor. No warranties expressed or implied. Your mileage may vary. Fnord.

I hope this will give people a pretty accurate idea of how big a grain of salt to take them with…