From Wikipedia, the free encyclopedia
Jump to: navigation, search

Strong typing and weak typing are terms used in computer science and computer programming to describe the manner in which restrictions on how operations involving values of different data types can be intermixed.

Strong typing[edit]

Type system is said to feature strong typing when it specifies one or more restrictions on how operations involving values of different data types can be intermixed. The opposite of strong typing is weak typing. Weak typing may be considered the opposite of strong typing in comparing the type system of different programming languages.

Definition in computer literature[edit]

Some of the factors which writers have qualified as "strong typing" include:

  • Absence of unchecked run-time type errors. This definition comes from [[Luca

Cardelli]]'s article Typeful Programming. [1] In other writing, the absence of unchecked run-time errors is referred to as safety or type safety; Tony Hoare's early papers call this property security.

  • Strong guarantees about the run-time behavior of a program

before program execution, whether provided by static analysis, the execution semantics of the language or another mechanism.

  • Type safety; that is, at compile or run time, the rejection of operations or function calls which attempt to disregard data types. In a more rigorous setting, type safety is proved about a formal language by proving progress and preservation.

special case of that with even stronger constraints, the guarantee that type-matching failures would never happen at runtime (which would also satisfy the constraint of "no undefined behavior" after type-matching failures, since the latter would never happen anyway).

  • The mandatory requirement, by a language definition, of

compile-time checks for type constraint violations. That is, the compiler ensures that operations only occur on operand types that are valid for the operation. However, that is also the definition of static typing, leading some experts to state: "Static typing is often confused with StrongTyping". [2]

  • Fixed and invariable typing of data objects.

The type of a given data object does not vary over that object's lifetime. For example, class instances may not have their class altered.

  • The absence of ways to evade the type system. Such

evasions are possible in languages that allow programmer access to the underlying representation of values, i.e., their bit-pattern.

that are inserted by the compiler on the programmer's behalf. For these authors, a programming language is strongly typed if type conversions are allowed only when an explicit notation, often called a cast, is used to indicate the desire of converting one type to another.

  • Disallowing any kind of type conversion. Values of one

type cannot be converted to another type, explicitly or implicitly.

  • A complex, fine-grained type system with compound types.

well-defined type which implicitly defines the legal values of and operations on the object. The language guarantees that it will prohibit illegal values and operations, by some mixture of compile- and run-time checking."[3]


Most generally, "strong typing" implies that the [[programming language]] places severe restrictions on the intermixing that is permitted to occur, preventing the compiling or running of source code which uses data in what is considered to be an invalid way. For instance, an addition operation may not allow to add an integer to a [[String (computer science)|string]] value; a procedure which operates upon linked lists may not be used upon numbers. However, the nature and strength of these restrictions is highly variable.



                 a = 2 b = "2" concatenate(a, b) # Returns "22" add(a, b) # Returns 4


a = 2 b = "2" concatenate(a, b) # Type Error add(a, b) # Type Error concatenate(str(a), b) # Returns "22" add(a, int(b)) # Returns 4

|- ! Languages | BASIC, JavaScript, Perl, PHP, Rexx| ActionScript 3, C++, C#, Java, Python, OCaml|}

Variation across programming languages[edit]

Note that some of these definitions are contradictory, others are merely orthogonal, and still others are special cases (with additional constraints) of other, more "liberal" (less strong) definitions. Because of the wide divergence among these definitions, it is possible to defend claims about most programming languages that they are either strongly or weakly typed. For instance:

C#, Pascal, Ada and C require all variables to have a defined type and support the use of explicit casts of arithmetic values to other arithmetic types. Java, C#, Ada and Pascal are often said to be more strongly typed than C, a claim that is probably based on the fact that C supports more kinds of implicit conversions, and C also allows pointer values to be explicitly cast while Java and Pascal do not. Java itself may be considered more strongly typed than Pascal as manners of evading the static type system in Java are controlled by the Java Virtual Machine's dynamic type system. C# is similar to Java in that respect, though it allows disabling dynamic type checking by explicitly putting code segments in an "unsafe context". Pascal's type system has been described as "too strong", because the size of an array or string is part of its type, making some programming tasks very difficult.[4][5] *The object-oriented programming languages Smalltalk, Ruby, Python, and Self are all "strongly typed" in the sense that typing errors are prevented at runtime and they do little implicit type conversion, but these languages make no use of static type checking: the compiler does not check or enforce type constraint rules. The term duck typing is now used to describe the dynamic typing paradigm used by the languages in this group. *The Lisp family of languages are all "strongly typed" in the sense that typing errors are prevented at runtime. Some Lisp dialects like Common Lisp or Clojure do support various forms of type declarations[6] and some compilers (CMUCL[7] and related) use these declarations together with type inference to enable various optimizations and also limited forms of compile time type checks.

and Haskell have purely static type systems, in which the compiler automatically infers a precise type for all values. These languages (along with most functional languages) are considered to have stronger type systems than Java, as they permit no implicit type conversions. While OCaml's libraries allow one form of evasion (Object magic), this feature remains unused in most applications.

  • Visual Basic is a hybrid language. In addition to including

statically typed variables, it includes a "Variant" data type that can store data of any type. Its implicit casts are fairly liberal where, for example, one can sum string variants and pass the result into an integer literal. *Assembly language and Forth have been said to be untyped. There is no type checking; it is up to the programmer to ensure that data given to functions is of the appropriate type. Any type conversion required is explicit. For this reason, writers who wish to write unambiguously about type systems often eschew the term "strong typing" in favor of specific expressions such as "type safety".

Weak typing[edit]

Weak typing and coercion[edit]

Aahz writes that "Coercion occurs when you have a statically-typed language and you use the syntactic features of the language to force the usage of one type as if it were a different type (consider the common use of void* in C). Coercion is usually a symptom of weak typing. Conversion, OTOH, creates a brand-new object of the appropriate type." [8]

GCC describes this as type-punning and warns that it will break strict aliasing. Thiago Macieira discusses several problems that can arise when type-punning causes the compiler to make inappropriate optimizations.[9]

Weak typing and pointers[edit]

Many languages offer weak typing via pointers. With pointers the value in question can be manipulated via direct memory access. This must be done with great care to avoid corrupting the value.

Many languages that are normally thought of as strongly typed still offer the ability to use pointers or other forms of direct memory manipulation. Examples of this include C# and Visual Basic. The former has rarely used language support for pointers inside unsafe blocks; both also can use the Marshal class to write directly to pointers.[10]

Weak typing and unions[edit]

Unions can be used to introduce weak typing. In the article titled A hacked Boolean, Bill McCarthy demonstrates how a Boolean value in .NET programming may become internally corrupted so that two values may both be "true" and yet still be considered unequal to each other.[11]

A common mistake when using the VARIANT union in COM programming is to forget to check the vt field, which indicates which type the value should be treated as.[12]

Strong typing[edit]

Jones and Liskov described a strong-typed language as one in which "each type defines a set of primitive operations that are the only direct means for manipulating objects of that type."[13]

Jackson wrote that "In a strongly typed language each data area will have a distinct type and each process will state its communication requirements in terms of these types." [14]

== Confusion with implicit type conversion and static vs dynamic typing == Many languages allow implicit type conversion where in it will try to coerce values into compatible types in order to perform an operation. A common example is implicitly converting strings to a numeric type or vice-versa. When the implicit conversion is not desirable this is often referred to as weak typing.

While many consider languages that allow implicit type conversion to be weakly typed, others argue that is really a facet of dynamic typing. Aahz writes, "Historically, 'strong typing' has been associated with static typing. Languages noted for strong typing include Pascal and Ada; languages noted for weak typing (most notoriously BASIC) had primarily dynamic typing. But the language that ought to be most notorious for weak typing has static typing: C/C++."[8]

A passage in Encapsulated data types and generic procedures by Demers, Donahue, Teitelbaum and Williams supports Aahz’s assertion. "PL/I external procedures are an example of a language construct that is statically, but weakly typed." [15]

== See also == 

showing whether or not they are strongly typed *Type system


  1. ^ page 3
  2. ^ [ Cunningham & Cunningham Wiki]
  3. ^ [ Brian Kernighan in Why Pascal is not my favourite language]
  4. ^ [ Infoworld April 25th 1983]
  5. ^ [ Brian Kernighan: Why Pascal is not my favourite language]
  6. ^ [ Common Lisp HyperSpec, Types and Classes]
  7. ^ [ CMUCL User's Manual: The Compiler, Types in Python]
  8. ^ a b [ Typing: Strong vs. Weak, Static vs. Dynamic]
  9. ^ Type-punning and strict-aliasing, Thiago Macieira [1]
  10. ^ [ Marshal.WriteInt32 Method (IntPtr, Int32)]
  11. ^ [ A hacked Boolean]
  12. ^ [ VARIANT and VARIANTARG, MSDN Library]
  13. ^ Programming with abstract data types, B Liskov, A Jones, ACM Sigplan Notices, 1974 [2]
  14. ^ Parallel processing and modular software construction, K. Jackson, Lecture Notes in Computer Science, 1977, Volume 54/1977, 436-443, doi:10.1007/BFb0021435 [3]
  15. ^ Encapsulated data types and generic procedures, Lecture Notes in Computer Science, 1977, Volume 54/1977, 171-214, doi:10.1007/BFb0021423 [4]

Category:Type theory Category:Programming language classification