Weak typing language often allow forcing the compiler to arbitrarily interpret a data item as having different representations—this can be a non-obvious programming error, or a technical method to directly deal with underlying hardware.
In most languages, the word coercion is used to denote an implicit conversion, either during compilation or during run time.
In most ALGOL-like languages, such as Pascal, Modula-2, Ada and Delphi, conversion and casting are distinctly different concepts.
The storage needs may change as a result of the conversion, including a possible loss of precision or truncation.
The word cast, on the other hand, refers to explicitly changing the interpretation of the bit pattern representing a value from one type to another.
For example, 32 contiguous bits may be treated as an array of 32 Booleans, a 4-byte string, an unsigned 32-bit integer or an IEEE single precision floating point value.
Because the stored bits are never changed, the programmer must know low level details such as representation format, byte order, and alignment needs, to meaningfully cast.
In a mixed-type expression, data of one or more subtypes can be converted to a supertype as needed at runtime so that the program will run correctly.
This can lead to unintuitive behavior, as demonstrated by the following code: On compilers that implement floats as IEEE single precision, and ints as at least 32 bits, this code will give this peculiar print-out: Note that 1 represents equality in the last line above.
The conversion causes loss of precision, which makes the values equal before the comparison.
Unlike some other type conversions, promotions never lose precision or modify the value stored in the object.
In this rule, compatible with means that the type of the source expression either conforms to or converts to that of the target.
To handle an assignment with original source and target reversed: the class STRING_8 also contains a conversion query to_cil which will produce a System.String from an instance of STRING_8.
If it is not the case, subsequent code which relies on the behaviour of HTMLCanvasElement will not perform correctly, as in Typescript there is no runtime checking for type assertions.
This allows unsafe type assertions to be contained in the checker function instead of littered around the codebase.