4

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?

Community
  • 1
  • 1
Heinzi
  • 151,145
  • 51
  • 326
  • 481
  • My understanding is that `String` is the exact same as `System.String` because you have always have either an implicit or explicit ns import for `System`. It's not like the `int` alias for `System.Int32`. – rory.ap Dec 29 '15 at 15:12
  • 2
    I don't see any other meaning for VB's `[]` [other than being like C#'s `@`](http://stackoverflow.com/q/6413343/11683). But it would be interesting to be proved wrong, +1. – GSerg Dec 29 '15 at 15:13
  • @roryap: I assume that it is not the same: Visual Studio gives `String` the same color as `Date`, not the same color as `DateTime`. We'd have to check the VB specification to be 100% sure, but I'm pretty sure that String is an explicit VB keyword. – Heinzi Dec 29 '15 at 15:15
  • 9
    What has not been said on this question? [What's the difference between String and string?](http://stackoverflow.com/questions/7074/whats-the-difference-between-string-and-string) – Steve Dec 29 '15 at 15:16
  • 2
    @Heinzi: That's just because they're keywords. – SLaks Dec 29 '15 at 15:16
  • @SLaks: That's my point. roryap claimed that `String` is *not* a keyword but rather simply the type name of `System.String` due to VB's implicit `System` import. I argued that this is not the case and that `String` *is* a keyword. – Heinzi Dec 29 '15 at 15:17
  • I can't edit my first comment now, but I meant `Integer` alias, not `int`. VB vs. C#. – rory.ap Dec 29 '15 at 15:19
  • Okay here's another potentially-unsubstantiated postulation on my part, but I'm going to lob it out there nonetheless: in general, there are neither advantages nor disadvantages to using aliases in .NET other than the obvious advantage of their brevity compared with their targets. If there were disadvantages, they wouldn't exist as neither MS nor the community would allow them. – rory.ap Dec 29 '15 at 15:23
  • @roryap: I think so, too. However, since the Roslyn developers are very smart guys, I don't want to rule out the possibility that I'm mistaken and that their usage of `[String]` actually makes sense somehow. – Heinzi Dec 29 '15 at 15:28
  • 1
    Language designers use keywords for primary data types to insulate themselves from implementation changes. String used to be a BSTR, Integer used to store 16 bits, etcetera. Whether 50 years from now String is still going to map to System.String is a question that requires a time machine to answer. History certainly suggests the odds are low. It already happened to some degree, it actually maps to HSTRING in Universal apps for example. – Hans Passant Dec 29 '15 at 15:48
  • 1
    I disagree that this is not a dupe. The answer to this question is inherent in the accepted answer to the linked one above. – TylerH Jan 01 '16 at 06:25
  • @TylerH: If the linked answer were about VB.NET (rather than C#), I might agree. Yes, I know that they are very similar, and I'll gladly dupe-hammer a purely "class-library based" C# question if I find a VB.NET dupe. However, this question is about language built-ins, which might (or might not) behave similarly. Implicitly assuming that results from the C# spec carry over to similarly-named keywords of the VB.NET spec is not justified, in my opinion. (However, explicitly stating such a similarity in an answer and providing appropriate references (see Bjørn-Roger's comment) would be fine.) – Heinzi Jan 01 '16 at 09:24
  • 1
    In C# the question could have been "What's the advantage of `@String` (verbatim identifier as name of the `System.String` type) over `string` (language keyword, alias of said type)?" and that has been answered in the linked question already. – Wormbo Jan 01 '16 at 09:38
  • @Wormbo: Yes, but this is not C#. The C# spec might be similar to the VB spec in many regards, but they are by no means equal. – Heinzi Jan 01 '16 at 09:42
  • I'm very aware they are not equal, but still the alias name ("built-in type") and the (escaped) type name itself, which are the core of your question, refer to the same .NET type. That is, of course, unless you use `Imports` or other means to have the identifier `[String]` refer to something other than `System.String`. But seriously, that'd be among "worst practices" for various reasons you hopefully agree to. – Wormbo Jan 01 '16 at 12:24
  • @Wormbo: Of course, I agree to that. Let me phrase the question this way: "*Is there any VB.NET magic that makes using `String` in any way different than `[String]`?*". Does that make it clearer that a C# question cannot *by definition* be a duplicate? – Heinzi Jan 01 '16 at 19:24
  • To all commenters: Thank you for your feedback and and for helping me improve the question. I'll flag the comment thread for removal tomorrow. – Heinzi Jan 03 '16 at 10:44

1 Answers1

0

I think that using String (referring to (1)) would be more continuous than [String]. Using [String] all over the place just simply does not look good in VB's syntax colors because it looks like an ordinary type and not a keyword. I think that there is no conceivable advantage of using [String] instead of String in code other than its looks when colored by the VB syntax.

Happypig375
  • 935
  • 10
  • 29