Historical Origins and Design Decisions of the Arrow Operator (->) in C

Historical Origins of the Arrow Operator

In early versions of the C language, the arrow operator -> had semantics completely different from modern C. According to the 1975 C Reference Manual (CRM), structure members played the role of global offset identifiers in the language design. Each structure member name had independent global significance and had to be either unique within the translation unit or represent the same offset value.

This design allowed developers to write code like:

int i = 5;
i->b = 42;  /* Write 42 into int at address 7 */
100->a = 0; /* Write 0 into int at address 100 */

The first assignment was interpreted by the compiler as "take address 5, add offset 2 to it, and assign 42 at the resultant address." This meant the left operand of the arrow operator could be any numerical address, whether pointer or integer, without type restrictions.

Limitations and Design of the Dot Operator

In the CRM version of C, the left operand of the dot operator . was required to be an lvalue—this was the only requirement for this operator. Notably, CRM did not require the left operand of the dot operator to have a struct type; it only needed to be any writable memory block.

This design allowed developers to write seemingly type-mismatched code:

struct S { int a, b; };
struct T { float x, y, z; };

struct T c;
c.b = 55;

In this case, the compiler would write 55 into an int value positioned at byte-offset 2 in the continuous memory block known as c, even though type struct T had no field named b. The compiler did not care about the actual type of c at all, only that c was an lvalue.

Evolution of Operator Functionality

In K&R C, many features originally described in CRM were significantly reworked. The concept of "structure member as global offset identifier" was completely removed, and the functionality of the arrow operator became fully identical to the combination of * and ..

From a historical perspective, C evolved from the typeless B language, which in turn derived from BCPL. These early languages were typeless, with all variables being word-sized values that could represent signed integers, unsigned integers, characters, or pointers. In this context, operators were responsible for determining the type meaning of operands.

Type System and Backward Compatibility

Early C continued the tradition of operators determining the meaning of values. As Dennis Ritchie noted in "The Development of the C Language": "Beguiled by the example of PL/I, early C did not tie structure pointers firmly to the structures they pointed to, and permitted programmers to write pointer->member almost without regard to the type of pointer; such an expression was taken uncritically as a reference to a region of memory designated by the pointer, while the member name specified only an offset and a type."

As the language matured, backward compatibility became an important consideration. Ritchie emphasized: "As should be clear from the history above, C evolved from typeless languages. It did not suddenly appear to its earliest users and developers as an entirely new language with its own rules; instead we continually had to adapt existing programs as the language developed, and make allowance for an existing body of code."

Deep Reasons Behind Design Decisions

The existence of the arrow operator is not merely syntactic sugar but reflects the historical trajectory of C's evolution from a typeless system to a typed system. In embryonic C, compilers were not sophisticated enough to "know" the type of operands, thus requiring two distinct operators to clearly differentiate between different memory access patterns.

Although modern C compilers have sufficient information to distinguish these cases, maintaining compatibility with existing code prevented fundamental changes to operator semantics. This design decision exemplifies the balance between pragmatism and theoretical elegance in programming language design.