330 Chapter 7 Expressions and Assignment Statements
in many cases, integers are stored in 32 bits, which allows at least nine decimal dig-
its of precision. But floating-point values are also stored in 32 bits, with only about
seven decimal digits of precision (because of the space used for the exponent). So,
integer-to-floating-point widening can result in the loss of two digits of precision.
Coercions of nonprimitive types are, of course, more complex. In Chapter 5,
the complications of assignment compatibility of array and record types were
discussed. There is also the question of what parameter types and return types
of a method allow it to override a method in a superclass—only when the types
are the same, or also some other situations. That issue, as well as the concept
of subclasses as subtypes, is discussed in Chapter 12.
Type conversions can be either explicit or implicit. The following two
subsections discuss these kinds of type conversions.7.4.1 Coercion in Expressions
One of the design decisions concerning arithmetic expressions is whether
an operator can have operands of different types. Languages that allow such
expressions, which are called mixed-mode expressions, must define conven-
tions for implicit operand type conversions because computers do not have
binary operations that take operands of different types. Recall that in Chap-
ter 5, coercion was defined as an implicit type conversion that is initiated by
the compiler. Type conversions explicitly requested by the programmer are
referred to as explicit conversions, or casts, not coercions.
Although some operator symbols may be overloaded, we assume that a
computer system, either in hardware or in some level of software simulation,
has an operation for each operand type and operator defined in the language.^6
For overloaded operators in a language that uses static type binding, the com-
piler chooses the correct type of operation on the basis of the types of the
operands. When the two operands of an operator are not of the same type and
that is legal in the language, the compiler must choose one of them to be
coerced and supply the code for that coercion. In the following discussion, the
coercion design choices of several common languages are examined.
Language designers are not in agreement on the issue of coercions in arith-
metic expressions. Those against a broad range of coercions are concerned
with the reliability problems that can result from such coercions, because they
reduce the benefits of type checking. Those who would rather include a wide
range of coercions are more concerned with the loss in flexibility that results
from restrictions. The issue is whether programmers should be concerned with
this category of errors or whether the compiler should detect them.
As a simple illustration of the problem, consider the following Java code:int a;
float b, c, d;...
d = b * a;
6. This assumption is not true for many languages. An example is given later in this section.