What is and what is the explanation for type-safe in C#?

Question

Not being able to understand the concept of type-safe in C# and what is its use, since C# is type-safe.

Answer 1

I will give a summary to laypeople, I will not do here a monograph on type theory.

Type security is the quality of doing operations on data only when the operation makes sense. Spoken languages type Safety have mechanisms that prevent the code to do what can go wrong by incompatibilities between types and use of a type where it cannot. It usually prevents a compilation from ending. It is the language that requires the code to respect established contracts.

Imagine trying to access an integer value in a value that is in memory as a floating point. Without the proper conversion this is a mistake, since the bit encoding of one of them has nothing to do with the other, internally it is different as we see where everything is number, not just abandon the decimal part, it is a totally different composition, they do not mix. But if the access makes the conversion automatically whenever you need, without causing unwanted results, then it is already safe.

Or imagine trying to access one substring() in a variable of the type date, or even try to make a ToString() in a variable that has not been initialized with an object (the variable still points to null).

Well-typed Programs cannot "go Wrong" -- Robin Milner

If this is carried to iron and fire, few languages, if any, can be considered safe in typing. Some people say this about Haskell (and it’s exaggeration), but not even about ML that he created himself (only the SML that came after did it) say it’s 100% safe. And he is the creator of type inference that makes it easy to keep typing safe and simple by avoiding the explicit manifestation of the type.

It is very difficult to ensure that everything will work. It is mathematically possible, but impractical in most cases. Hence these languages that avoid type punning are not used.

It is generally considered as type safe languages that solve all type problems, including erroneous memory position access improperly (no wild pointers that access areas not allowed for that data) or access areas not reserved for the data of that type.

It also considers semantics. A type that keeps temperature in Celsius scale and another in Kelvin scale (which I chose only to not have to write Fahrenheit :P), usually allow the same operations and have the same internal coding, usually composed of an integer or a standard floating point number, and even so they may be incompatible since the same internal number of each represents completely different valuations, to reconcile them would need a normalization.

Languages of Dynamic and mainly weak typing are insecure by nature. But strong static typing does not guarantee security by itself. For example, I have never seen a language that does not have Generics, or similar mechanism, be secure from the point of view of typing.

Some people consider that if the error is caught before running still ensures the security of types, then dynamic languages could be, since they give error before doing something. I find it naive and purposeless. If this is true then everything can be safe, even if it is not. I prefer to consider that any error caused by misuse of a data because of its kind violates type safety. I find this more universal.

100% security is a little complicated to perform and the languages that do this have difficulties to express well all situations. Especially in older languages because at first nobody valued this feature very much, and when they decide to do this they cannot abandon the legacy.

C#

C# is safe up to page 3. There are numerous situations where it is not safe to type. I am not even talking about the use of dynamic. Even the use of object is a problem except in very specific cases.

There are problems of variance that let do things that could not when there is subtype.

The use of null violates type security because there are cases where a variable refers to nothing when you expect a given that has the ability to do a number of specific things by being of that type.

Implicit or even explicit coercion that can go wrong also makes typing very insecure. Guaranteed coercion that always works and does not create ambiguity or confusion in its subsequent use does not breach security.

Context unsafe allows various type security problems.

Use of unions (struct with layout explicit that overlapping members) also creates complications for typing.

And I didn’t even mention going through it using code injection in CIL, so little errors in standard libraries that encourage wrong use.

And that’s all I remember now, there are other violations.

Some of these problems are being solved. Interestingly Java is less secure, but many people think it is not. In some ways even C++ is safer (but not in others). If it weren’t for marketing...

Rust is an example of security in several aspects, but still has several insecurities.

Most languages are pragmatic and give up 100% security to give more usability and flexibility in the language. But marketing says it’s type safe.

See also: What is typing style?.