Inside Arrays: Grounded at Zero
The introduction of .NET to VB required many changes in how VB worked: One of these changes was the removal of support for non-zero based arrays. Although .NET has a non-zero based single dimension array, it is a different type from the SZArray. If VB were to have supported non-zero-based arrays, it would have had to provide different syntax for SZArrays. Given the framework typically only uses and exposes SZArrays, it would also have meant that the uses for the non-zero based arrays would be limited. That's not to say a better solution wouldn't have been possible.
Rather than have a SZArray be a different type, the CLR team could have instead made all single dimension arrays the same type, and provided zero-based access to members alongside the access offset by the lower-bound. Then, the languages could choose to provide an implementation for either zero-based access, offset-based access, or both.
Unfortunately, that didn't happen, and the real value of adding potential complexities to the languages as they try to support both means of access is questionable. One reason people give for wanting non-zero based arrays include examples where data is stored against years. But in these cases, developers would probably be better off using a sparse array or generic Dictionary(Of TKey, TValue). The lack of support for non-zero based arrays does hit one group of people particularly hard: Those who like to think of arrays as having the first item being one. VB aided and nurtured a generation of developers with Option Base one.
The lack of one-based operations isn't limited to arrays; it's in all framework methods. Many of VB's methods on the other hand are one-based in an attempt to maintain compatibility with previous versions. This leads to a mismatch, such as IntStr being one-based, while String.IndexOf is zero-based. As you work with the framework, you are forced to think in terms of zero-based. Arrays cast as IList or the generic IList(Of T) lose all indication of lower-bound: Item can only be used practically if it's considered to be zero-based. The move from one-based to zero-based isn't a question of functionality; it's a question of perspective. A mix-and-match of one- and zero-based methods rapidly becomes confusing, and the chances of a coding slip up increase. There's a lot to be said for the simplicity of having everything zero-based.