Is C# a strongly typed or a weakly typed language?

Question

Can someone please clarify if C# a strongly typed or a weakly typed language? And explain the answer why.

if I have a function called concat that can take any object is this then considered weakly typed?

function concat(Object stuff)
{
   //do something here to stuff
}

Solution 1

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

Is C# a strongly typed or a weakly typed language?

Yes.

That is unhelpful.

I don't doubt it. Interestingly, if you rephrased the question as an "and" question, the answer would be the same.

What? You mean, is C# a strongly typed and a weakly typed language?

Yes, C# is a strongly typed language and a weakly typed language.

I'm confused.

Me too. Perhaps you should tell me precisely what you mean by "strongly typed" and "weakly typed".

Um. I don't actually know what I mean by those terms, so perhaps that is the question I should be asking. What does it really mean for a language to be "weakly typed" or "strongly typed"?

"Weakly typed" means "this language uses a type verification system that I find distasteful", and "strongly typed" means "this language uses a type system that I find attractive".

Solution 2

C# is strongly typed.

ECMA-334 Defines C# as "C# (pronounced “C Sharp”) is a simple, modern, object oriented, and type-safe programming language."

Wikipedia defines type safety

Type safety is synonymous with one of the many definitions of strong typing; but type safety and dynamic typing are mutually compatible.

Wikipedia defines strong-typing as

In computer science and computer programming, a type system is said to feature strong typing when it specifies one or more restrictions on how operations involving values of different data types can be intermixed. The opposite of strong typing is weak typing.

Perhaps it's better to ask if C# is a type-safe language since nobody can agree on what "strong" and "weak typing" really mean if the compiler will do type checking.

C# does have some dynamic language like constructs available but remarkably these are still type-safe at compile time.

Beginning in Visual C# 3.0, variables that are declared at method scope can have an implicit type var. An implicitly typed local variable is strongly typed just as if you had declared the type yourself, but the compiler determines the type.

http://msdn.microsoft.com/en-us/library/bb383973.aspx

The dynamic keyword basically works the same way except it is evaluated at run-time instead of at compile time as the case with var.

Visual C# 2010 introduces a new type, dynamic. The type is a static type, but an object of type dynamic bypasses static type checking. In most cases, it functions like it has type object. At compile time, an element that is typed as dynamic is assumed to support any operation.

http://msdn.microsoft.com/en-us/library/dd264736.aspx

Solution 3

In general: C# is used in a strongly typed manner, meaning: a variable is declared of a specific Type (either: string, int, a user-defined type, etc.) and cannot, later, be assigned a value of a different type.

For example: You can't have the following in C#:

int i = 10;
i = "ten";

As in comments below, C# can be used differently.

Using "strong" typing lets the editor/compiler alert you to mistakes, and lets the editor give you suggestions narrowed down to what you are likely going to need.

Solution 4

Here is a blog post on the subject from someone who was (at the time he wrote the post) one of the principal developers of the C# compiler.

In short, the question itself is flawed and cannot be reasonably answered in its current form.

Solution 5

There are many, many definitions of both strongly typed and weakly typed, to the point where you need to define what you mean by the term when you use it. A definition I find useful is "does the language force me to specify a type for things like parameters?" This separates languages like C# to one side and Javascript to the other, a distinction I find useful.

Requiring someone to name a type instead of relying on things like "duck typing" creates advantages in static analysis but disadvantages when it comes to specifying types that share common functionality. For this reason, many of these languages evolve elaborate type relation specification systems, typically first class-based programming and later elaborate template systems or inference systems so that programmers can say things like "type A is a subset of type B" or "type C is a metatype that can be applied to any other type that satisfies conditions D and E" and so on.

View more solutions

Comments

[BoltClock]

That's why close votes exist :P

[Servy]

MSDN is also wrong, in that it's trivial to write a C# program that is not strongly typed. C# can write strongly typed programs, but nothing forces you to.

[Servy]

@BoltClock Well, the answer is that there is no answer, as opposed to "None of us can figure out what the answer is." There is actually a fairly good explanation that can be given for why there can't be any answer, which is why I didn't vote to close.

[Mr. Young]

Why down-vote this answer. It's completely correct. Give an comment if you choose to down-vote. That way I can understand why you didn't like the answer.

[Servy]

There isn't any if's/and's/but's to this argument." Well, as "strongly typed" has no clear meaning, one cannot state whether it applies to a given language or not.

[Casper Leon Nielsen]

I gave you an upvote, but I guess the dw's comes from you asserting "There isn't any if's/and's/but's to this argument." I can give you a few clues on why that is not such a good thing to say: If you give an argument and the are "no counter arguments that are valid up front", then you are not really giving an argument at all, instead you are asserting something. Second: There certainly are ifs and buts: See the answer from Gideon that will be accepted shortly, if SO keeps its almost constant level of quality.

[Servy]

By that definition it's not possible to have a language that's not strongly typed, as all variables will almost always be of some type such as variant that represents "anything".

[Servy]

And yet there are a number of places in which C# allows the "duck typing" that you state is a trait of non-strongly typed languages. The most commonly known example would be the foreach loop, which works for any object that has a GetEnumerator method.

[Plynx]

@Servy that's not duck typing. It's not checking for the name "GetEnumerator", it's checking to see whether the type is declared as implementing System.Collections.IEnumerable or System.Collections.Generic.IEnumerable<T>.

[ispiro]

@Servy Perhaps I wasn't clear. I meant that a variable will be permanently set to a certain type. As opposed to, say, JavaScript where a variable can be a string and then an int etc.

[Servy]

You mean like in C# where I can assign a string to a variable of type object and then later assign an int to it?

[Marc Gravell]

@Plynx actually it kinda is; it is based on names/signatures, not a specific interface. Other examples would include LINQ and await.

[Marc Gravell]

@Plynx (with your comment edit) no, you are incorrect. foreach does not require those interfaces. Those interfaces guarantee those signatures, but the feature works just fine even without them.

[Plynx]

@MarcGravell Nice to know... I'm just going by the current docs and former knowledge. I haven't done much recent coding in C# since 4.0.

[Marc Gravell]

@Plynx that (foreach) has been the case since C# 1.2, and possibly even before then (I don't have the 1.0 spec to-hand). LINQ came in 3.5.

[Plynx]

@MarcGravell Neat, I learned something new. Seems the initial description in the docs for foreach is wrong msdn.microsoft.com/en-us/library/ttw7t8t6(v=vs.110).aspx and the details are in msdn.microsoft.com/en-us/library/9yb8xew9.aspx . Thanks!

[Servy]

Note that that is simply one example, and one that's more commonly known. There are a number of others. Marc has mentioned a few, and then of course there's dynamic, and beyond that there's everything that can be done in unsafe code to completely destroy any assumption that could be made about the state of the program in managed code.

[Mr. Young]

thanks for the fantastic feedback. I have adjusted my answer in response to the feedback. Maybe I can earn those points back.

[Servy]

@Mrshll187 Well, it's the only answer bar mine that doesn't state something that's provably wrong. Everything here is certainly as correct as can be expected given the question asked. The link should also have shown up for you in Google when you searched for answers.

[Plynx]

@Servy I think it goes to show that strong/weak typing is at best, a crude instrument for language classification. In general we programmers like to have access to both sets of features (if possible) for the opportunity to create coding structures of greater elegance. The primary use I have for the distinction is historical—I've found that languages that require type specifications tend to grow along similar paths, and languages that don't do likewise, although ultimately, they end up with optional characteristics of the other approach.

[Servy]

Based on your edit, you only demonstrate that C# can be used in a strongly typed manor; but note that you are not forced to do so. It enables the use of what you define as "strong typing" but that can be violated entirely in the language.

[Servy]

The definition you quote of strongly typed isn't particularly meaningful, I don't think any language in existence wouldn't meet it's criteria. It's also not a definition that is generally agreed on. Note that dynamic is specifically telling the compiler to stop doing type checking, so your later definition that type checking is done by the compiler is violated by it's existence.

[ispiro]

Actually, Even using object's, C# is partially strongly typed - You can't simply refer to a variable's properties. e.g. You can't set object i = "ten"; and then get i.Length.

[Servy]

@ispiro You can if you use dynamic. Likewise, you can use casting to tell the compiler to get you the Length property from the object in i. Casting in fact, by it's very nature, violates strong typing. It's entire purpose is to allow you to violate the compiler's type system.

[Mr. Young]

dynamic isn't telling the compiler to stop doing type checking. dynamic is of type ExpandoObject which is just more or less an key-value dictionary. public sealed class ExpandoObject : IDynamicMetaObjectProvider, IDictionary<string, Object>, ICollection<KeyValuePair<string, Object>>, IEnumerable<KeyValuePair<string, Object>>, IEnumerable, INotifyPropertyChanged

[Servy]

@Mr.Young dynamic is exactly telling the compiler to stop doing type checking; that's basically all it's doing. Any dynamic invocation involves creating a special instance of the C# compiler at runtime to determine what the appropriate resolution of the dynamic object's member should be. Not all dynamic objects are ExpandoObjects. ExpandoObjects are almost always used in a dynamic variable, because that's what they were built for, but not all dynamic objects are expando objects; in fact very few are.

[Mr. Young]

I did some research and found out that we are both right and wrong. Which is why there is so much confusion. From MSDN Magazine: The dynamic keyword acts as a static type declaration in the C# type system. This way C# got the dynamic features and at the same time remained a statically typed language. Why and how this decision was made is explained in the presentation “Dynamic Binding in C# 4” by Mads Torgersen at PDC09 (microsoftpdc.com/2009/FT31). When you use the dynamic keyword you tell the compiler to turn off compile-time checking. msdn.microsoft.com/en-us/magazine/gg598922.aspx

[Servy]

@Mr.Young So what's your point from that quote? When you use dynamic you remove all meaningful static typing, effectively turning it off whenever it's used. So while C# can be used while maintaining static typing, there are a number of ways of violating static typing. Dynamic is one, unsafe code is another, and even a basic cast is the simplest and easiest way of violating static typing, so C# is not an entirely statically typed language.

[Mr. Young]

let us continue this discussion in chat

[trysis]

Wikipedia pretty much confirmed that "strongly typed" and "weakly typed" don't usually mean anything, and one is used to praise languages & the other to criticize it. That article is more opinionated than most tbh.

[Daniel Westcott]

Try this: create a method that takes and returns an Int. Create a method which takes and returns a float. Call the float method from the Int method using the method input and see what you get back. What happened was that the Int was implicitly cast to a float...but of course cannot be implicitly cast back to an Int as precision would be lost. This is why I call C# "mostly strongly typed". Implicit casting of an Int to a Float is duck typing. Throwing the error when the Float isn't an Int is strong.