We all know that in C# it makes no difference whatsoever whether you use String
(the CLR class) or string
(the C# keyword). See the following question for details:
So far, I was under the impression that the same is true for VB.NET. The language specification even says (emphasis mine):
The primitive types are identified through keywords, which are aliases for predefined types in the System namespace. A primitive type is completely indistinguishable from the type it aliases: writing the reserved word Byte is exactly the same as writing System.Byte.
Thus, I was very surprised to see Visual Studio 2015 make a difference: Visual Studio allows you to specify your preference (Tools/Options/Text Editor/Basic/Code Style) of Framework names (Int32/Int64/DateTime/...) over the native VB keywords (Integer/Long/Date/...).
The thing is: Once you tell Visual Studio that you prefer the Framework names, auto-generated code uses [String]
(using the []
VB keyword escape, similar to C#'s @
) instead of String
(same for Object, Single, and all the other types where the VB keyword matches the Framework type name). I think this is wrong (and have filed a Connect issue), since the brackets clutter the code and, as demonstrated above, it does not make a semantic difference whether you use [String]
(effectively referencing System.String
due to VB's automatic System
import) or String
(the VB keyword aliasing System.String
).
However, since the Visual Studio developers are very smart guys, it is entirely possible that I just overlooked something and that it actually makes sense to use [String]
rather than String
, hence my question:
Is there any conceivable advantage of using [String]
instead of String
in Visual Basic or is the Visual Studio editor just "doing the wrong thing" and uselessly cluttering auto-generated code?