Is VB.NET weakly typed compared to C#

Yesterday I was at an interview where my interviewer (who admittedly didn't claim to be an expert on the subject) stated that "VB.NET is more weakly typed then C#" - (At the same time he couldn't recall an example).

This statement seemed incorrect to me (particularly given that both languages use the same framework libraries for their types) and I advised as such and that perhaps he was confused with the option to turn Option Strict or Option Infer on/off.

At the same time I know that VB.NET has situations where it will do type coercion - leading to occasionally unexpected result开发者_如何转开发s (although I also cant recall under what conditions) - (Actually I think I just remembered that it was mainly when performing arithmetic operations with different types - whereas other languages will force you to be explicit (?) ).

So could someone please clarify is VB.NET somehow more weakly typed then C# and if so could you provide examples?

"Weakly typed" and "strongly typed" are effectively meaningless without clarification. The way they are used they usually mean "the type system has features I do not like" or "the type system has features I do like". It sounds like your interviewer does not have a clear idea of what those terms mean, and therefore probably shouldn't be asking questions about them in interviews.

There are a lot of features of type systems that different people say are "strongly typed" vs "weakly typed". For example, some people say that "strongly typed" means "every object knows its own type at runtime". Some people say that "strongly typed" means that the compiler knows the exact type of every variable and expression. Some people say that it means that the compiler has inexact type bounds on every variable and expression. And so on. Every feature of type systems can count as points towards 'strong'.

I say abandon the whole ill-founded notion of "strong" and "weak" typing and talk about what you actually mean.

The differences between the C# and VB type systems are few, particularly since the addition of 'dynamic' to C# 4.0. Both C# and VB use the CLR type system, in which every object knows its own type, and in which illegal type conversions are detected by the runtime (either when the code runs or when it is passed through the verifier) and turned into exceptions. Both have single inheritance for classes and multiple inheritance for interfaces. Both make a distinction between value types and reference types. And so on.

The principle difference between C# and VB type systems is that VB supports optionally dialing down the compile time static type checking, and deferring type checking to runtime, more like a dynamically typed language. This is very handy when interoperating with object models that were designed for dynamic type systems. We added a similar feature to C# 4.0, but in keeping with C# 4.0's historical support of static typing, the feature is based on statically typing certain expressions as "dynamic", which are then resolved by starting up the type analyzer again at runtime and doing the type analysis against the live objects.

More on this subject can be found on my blog:

http://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language/

As an interview strategy, it would have been better to say "you're correct, it is more weakly typed, but only for particular settings like Option Strict Off or Option Infer off"

Most people are happier to be told "you're correct" rather than "you're confused" :)

(I've never really used VB before, so this is all new to me too)

They are referring to the Option Strict statement, or rather what happens when you omit it.

The following VB compiles and runs perfeclty as long as you have Option Explicit off:

Class Widget
    Sub Method1()

    End Sub
End Class

Sub Main()
    Dim someInt As Integer
    Dim someDouble As Double
    Dim someObj As Object = New Widget

    someDouble = 1234567890.9876542
    someInt = someDouble
    Call someObj.Method1()
    Call someObj.Method2() ' causes runtime error
End Sub

The above implicitly casts a double to an integer, calls a method Method1 on an Object reference and even calls a method Method2 (which doesn't even exist) - none of which will compile in C# or in VB with Option Strict On.

This definitely matches the definiton of "not as strongly typed" as C#, although the term seems to be fairly subjective.

Update: We can use ILSpy to reveal the "magic" going on here by looking at the compiled assembly (in C#):

object obj = new Module1.Widget();
double num = 1234567890.9876542;
int i = Math.Round(num);
NewLateBinding.LateCall(obj, null, "Method1", new object[0], null, null, null, true);
NewLateBinding.LateCall(obj, null, "Method2", new object[0], null, null, null, true);

This explains why the VB.Net compiler is able to do things that would otherwise seem to be illegal in the CLR, although it does seem to come with some sort of runtime performance penalty.

VB.NET allows both. As mentioned in the comments, you can set this in the project (or file) by setting Option Strict either ON or OFF.

The MSDN documentation here talks a bit more what the option does.