Differencebetween Casting and Coercing

What is the difference between casting and coercing?

Type Conversion:

The word conversion refers to either implicitly or explicitly changing a value from one data type to another, e.g. a 16-bit integer to a 32-bit integer.

The word coercion is used to denote an implicit conversion.

The word cast typically refers to an explicit type conversion (as opposed to an implicit conversion), regardless of whether this is a re-interpretation of a bit-pattern or a real conversion.

So, coercion is implicit, cast is explicit, and conversion is any of them.

---

Few examples (from the same source) :

Coercion (implicit):

double  d;
int     i;
if (d > i)      d = i;

Cast (explicit):

double da = 3.3;
double db = 3.3;
double dc = 3.4;
int result = (int)da + (int)db + (int)dc; //result == 9

What is the difference between conversion, casting and coercion?

[C++] What is the difference between conversion, casting and coercion?

• Conversion is the creation of a value from an expression, potentially changing the type of the resulting value.

• A cast is an explicit way to convert a value. Some conversions do not require a cast. Those are called implicit conversions. Example of an implicit conversion:

  int a = 42;
  long b = a; // type of expression a is int,
              // but implicitly converted to long
  

  Same example using a cast to make the conversion explicit:

  long b = static_cast<long>(a);
  

• Type "coercion" is colloquially used as a synonym of conversion, but the term is not used in the specification of the C++ language. The term is used for example in the ECMAScript language (i.e. JavaScript). Example of a coercion in JS:

  Number("42") + 42  // == 84
  "42" + 42          // == "4242"
  

What's the difference between casting and coercion in Python?

I think "casting" shouldn't be used for Python; there are only type conversion, but no casts (in the C sense). A type conversion is done e.g. through int(o) where the object o is converted into an integer (actually, an integer object is constructed out of o). Coercion happens in the case of binary operations: if you do x+y, and x and y have different types, they are coerced into a single type before performing the operation. In 2.x, a special method __coerce__ allows object to control their coercion.

What's the difference between casting and coercing a pointer in swift?

unsafeBitCast is an unsafe conversion between any two Swift types of the same size. That is, you can write unsafeBitCast(x, UnsafePointer<MyStruct>.self), but you could have also written unsafeBitCast(x, MyClass.self) or unsafeBitCast(x, Int.self). This is generally very unsafe, because Swift doesn't guarantee much about the memory layout of its types. Using UnsafePointer or Unmanaged might be better options in your case.

The "coercion" UnsafePointer<MyStruct>(x) isn't really a special language feature, it's just an UnsafePointer initializer which takes another UnsafePointer. Its effect is to reinterpret the value at the same memory address as a different type, similar to casting between pointer types in C (or static_casting in C++). The conversion between the two Swift types (the two variants of UnsafePointer) is safe, but of course they are still UnsafePointers, so you must be certain you're accessing the memory correctly; you are still responsible for allocation and deallocation.

What is the difference between autoboxing and coercion?

Coercion is another name for an implicit type cast, i.e. one mandated by the language rules, and not explicitly added by the programmer.

Difference between casting and using the Convert.To() method

Even if you may see them somehow as equivalent they're completely different in purpose. Let's first try to define what a cast is:

Casting is the action of changing an entity of one data type into another.

It's a little bit generic and it's somehow equivalent to a conversion because a cast often has the same syntax of a conversion so the question should be when a cast (implicit or explicit) is allowed by the language and when do you have to use a (more) explicit conversion?

Let me first draw a simple line between them. Formally (even if equivalent for language syntax) a cast will change the type while a conversion will/may change the value (eventually together with the type). Also a cast is reversible while a conversion may not be.

This topic is pretty vast so let's try to narrow it a little bit by excluding custom cast operators from the game.

Implicit casts

In C# a cast is implicit when you won't lose any information (please note that this check is performed with types and not with their actual values).

Primitive types

For example:

int tinyInteger = 10;
long bigInteger = tinyInteger;

float tinyReal = 10.0f;
double bigReal = tinyReal;

These casts are implicit because during the conversion you won't lose any information (you just make the type wider). Vice versa implicit cast isn't allowed because, regardless of their actual values (because they can be checked only at run-time), during the conversion you may lose some information. For example this code won't compile because a double may contain (and actually it does) a value not representable with a float:

// won't compile!
double bigReal = Double.MaxValue;
float tinyReal = bigReal;

Objects

In case of an object (a pointer to) the cast is always implicit when the compiler can be sure that the source type is a derived class (or it implements) the type of the target class, for example:

string text = "123";
IFormattable formattable = text;

NotSupportedException derivedException = new NotSupportedException();
Exception baseException = derivedException;

In this case the compiler knows that string implements IFormattable and that NotSupportedException is (derives from) Exception so the cast is implicit. No information is lost because objects don't change their types (this is different with structs and primitive types because with a cast you create a new object of another type), what changes is your view of them.

Explicit casts

A cast is explicit when the conversion isn't done implicitly by the compiler and then you must use the cast operator. Usually it means that:

• You may lose information or data so you have to be aware of it.
• The conversion may fail (because you can't convert one type to the other) so, again, you must be aware of what you're doing.

Primitive types

An explicit cast is required for primitive types when during the conversion you may lose some data, for example:

double precise = Math.Cos(Math.PI * 1.23456) / Math.Sin(1.23456);
float coarse = (float)precise;

float epsilon = (float)Double.Epsilon;

In both examples, even if the values fall within the float range, you'll lose information (in this case precision) so the conversion must be explicit. Now try this:

float max = (float)Double.MaxValue;

This conversion will fail so, again, it must be explicit so you're aware of it and you may do a check (in the example the value is constant but it may come from some run-time computations or I/O). Back to your example:

// won't compile!
string text = "123";
double value = (double)text;

This won't compile because the compiler can't convert text to numbers. Text may contain any characters, not numbers only and this is too much, in C#, even for an explicit cast (but it may be allowed in another language).

Objects

Conversions from pointers (to objects) may fail if the types are unrelated, for example this code won't compile (because the compiler knows there is no possible conversion):

// won't compile!    
string text = (string)AppDomain.Current;
Exception exception = (Exception)"abc";

This code will compile but it may fail at run-time (it depends on the effective type of casted objects) with an InvalidCastException:

object obj = GetNextObjectFromInput();
string text = (string)obj;

obj = GetNextObjectFromInput();
Exception exception = (Exception)obj;

Conversions

So, finally, if casts are conversions then why do we need classes like Convert? Ignoring the subtle differences that come from Convert implementation and IConvertible implementations actually because in C# with a cast you say to the compiler:

trust me, this type is that type even if you can't know it now, let me do it and you'll see.

-or-

don't worry, I don't care if something will be lost in this conversion.

For anything else a more explicit operation is needed (think about implications of easy casts, that's why C++ introduced long, verbose and explicit syntax for them). This may involve a complex operation (for string -> double conversion a parsing will be needed). A conversion to string, for example, is always possible (via ToString() method) but it may mean something different from what you expect so it must be more explicit than a cast (more you write, more you think about what you're doing).

This conversion can be done inside the object (using known IL instructions for that), using custom conversion operators (defined in the class to cast) or more complex mechanisms (TypeConverters or class methods, for example). You're not aware of what will happen to do that but you're aware it may fail (that's why IMO when a more controlled conversion is possible you should use it). In your case the conversion simply will parse the string to produce a double:

double value = Double.Parse(aStringVariable);

Of course this may fail so if you do it you should always catch the exception it may throw (FormatException). It's out of topic here but when a TryParse is available then you should use it (because semantically you say it may not be a number and it's even faster...to fail).

Conversions in .NET can come from a lot of places, TypeConverter, implicit/explicit casts with user defined conversion operators, implementation of IConvertible and parsing methods (did I forget something?). Take a look on MSDN for more details about them.

To finish this long answer just few words about user defined conversion operators. It's just sugar to let the programmer use a cast to convert one type to another. It's a method inside a class (the one that will be casted) that says "hey, if he/she wants to convert this type to that type then I can do it". For example:

float? maybe = 10; // Equals to Nullable<float> maybe = 10;
float sure1 = (float)maybe; // With cast
float sure2 = maybe.Value; // Without cast

In this case it's explicit because it may fail but this is let to the implementation (even if there are guidelines about this). Imagine you write a custom string class like this:

EasyString text = "123"; // Implicit from string
double value = (string)text; // Explicit to double

In your implementation you may decide to "make programmer's life easier" and to expose this conversion via a cast (remember it's just a shortcut to write less). Some language may even allow this:

double value = "123";

Allowing implicit conversion to any type (check will be done at run-time). With proper options this can be done, for example, in VB.NET. It's just a different philosophy.

What can I do with them?

So the final question is when you should use one or another. Let's see when you can use an explicit cast:

• Conversions between base types.
• Conversions from object to any other type (this may include unboxing too).
• Conversions from a derived class to a base class (or to an implemented interface).
• Conversions from one type to another via custom conversion operators.

Only the first conversion can be done with Convert so for the others you have no choice and you need to use an explicit cast.

Let's see now when you can use Convert:

• Conversions from any base type to another base type (with some limitations, see MSDN).
• Conversions from any type that implements IConvertible to any other (supported) type.
• Conversions from/to a byte array to/from a string.

Conclusions

IMO Convert should be used each time you know a conversion may fail (because of the format, because of the range or because it may be unsupported), even if the same conversion can be done with a cast (unless something else is available). It makes clear to who will read your code what's your intent and that it may fail (simplifying debug).

For everything else you need to use a cast, no choice, but if another better method is available then I suggest you use it. In your example a conversion from string to double is something that (especially if text comes from user) very often will fail so you should make it as much explicit as possible (moreover you get more control over it), for example using a TryParse method.

Edit: what's the difference between them?

According to updated question and keeping what I wrote before (about when you can use a cast compared to when you can/have to use Convert) then last point to clarify is if there are difference between them (moreover Convert uses IConvertible and IFormattable interfaces so it can perform operations not allowed with casts).

Short answer is yes, they behave differently. I see the Convert class like a helper methods class so often it provides some benefit or slightly different behaviors. For example:

double real = 1.6;
int castedInteger = (int)real; // 1
int convertedInteger = Convert.ToInt32(real); // 2

Pretty different, right? The cast truncates (it's what we all expect) but Convert performs a rounding to nearest integer (and this may not be expected if you're not aware of it). Each conversion method introduces differences so a general rule can't be applied and they must be seen case by case...19 base types to convert to every other type...list can be pretty long, much better to consult MSDN case by case!

What exactly is Type Coercion in Javascript?

Type coercion means that when the operands of an operator are different types, one of them will be converted to an "equivalent" value of the other operand's type. For instance, if you do:

boolean == integer

the boolean operand will be converted to an integer: false becomes 0, true becomes 1. Then the two values are compared.

However, if you use the non-converting comparison operator ===, no such conversion occurs. When the operands are of different types, this operator returns false, and only compares the values when they're of the same type.

Coercion isn't only done by comparison operators, although they're the only ones that have both "strict" and "loose" variants. Most arithmetic operators will automatically converse non-numeric arguments to numbers, e.g. "50" / 5 is treated as 50 / 5. There are also many built-in functions and methods that require string arguments; if you give them something else, they'll automatically coerce them to strings.

But be careful -- + is both the arithmetic addition operator and the string concatenation operator -- if you do string + number, it converts the number to a string and concatenates, rather than converting the string to a number and adding. This is the source of many errors made when performing arithmetic on user input, since input is a string unless you explicitly convert it.

You can find a good explanation of JavaScript's coercion rules in You Don't Know JS and more reference-oriented documentation in MDN.

What is the difference between type conversion and type assertion?

A type assertion asserts that t (an interface type) actually is a aType and t will be an aType; namely the one wrapped in the t interface. E.g. if you know that your var reader io.Reader actually is a *bytes.Buffer you can do var br *bytes.Buffer = reader.(*bytes.Buffer).

A type conversion converts one (non-interface) type to another, e.g. a var x uint8 to and int64 like var id int64 = int64(x).

Rule of thumb: If you have to wrap your concrete type into an interface and want your concrete type back, use a type assertion (or type switch). If you need to convert one concrete type to an other, use a type conversion.

---

Related Topics