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.
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
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.  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.
- The guarantee that a well-defined error or exceptional behavior (as opposed to an undefined behavior) occurs as soon as a type-matching failure happens at runtime, or, as a
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". 
- Fixed and invariable typing of data objects.
- 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.
- Omission of implicit type conversion, that is, conversions
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.
- Brian Kernighan: "[...] each object in a program has a
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."
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
Variation across programming languages
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. *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 and some compilers (CMUCL 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 and coercion
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." 
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.
Weak typing and pointers
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.
Weak typing and unions
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.
== 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++."
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." 
== See also ==
- Data type includes a more thorough discussion of typing issues
- Comparison of programming languages has a table of languages
showing whether or not they are strongly typed *Type system
- ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/SRC-045.pdf page 3
- [http://c2.com/cgi/wiki?StaticTyping Cunningham & Cunningham Wiki]
- [http://www.cs.virginia.edu/~cs655/readings/bwk-on-pascal.html Brian Kernighan in Why Pascal is not my favourite language]
- [http://books.google.co.uk/books?id=7i8EAAAAMBAJ&pg=PA66&lpg=PA66&dq=pascal+type+system+%22too+strong%22&source=bl&ots=PGyKS1fWUb&sig=ebFI6fk_yxwyY4b7sHSklp048Q4&hl=en&ei=lSmjTunuBo6F8gPOu43CCA&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBsQ6AEwAA#v=onepage&q=pascal%20type%20system%20%22too%20strong%22&f=false Infoworld April 25th 1983]
- [http://www.cs.virginia.edu/~cs655/readings/bwk-on-pascal.html Brian Kernighan: Why Pascal is not my favourite language]
- [http://www.lispworks.com/documentation/HyperSpec/Body/04_.htm Common Lisp HyperSpec, Types and Classes]
- [http://common-lisp.net/project/cmucl/doc/cmu-user/compiler.html#toc123 CMUCL User's Manual: The Compiler, Types in Python]
- [http://www.artima.com/weblogs/viewpost.jsp?thread=7590 Typing: Strong vs. Weak, Static vs. Dynamic]
- Type-punning and strict-aliasing, Thiago Macieira 
- [http://msdn.microsoft.com/en-us/library/62t454ew.aspx Marshal.WriteInt32 Method (IntPtr, Int32)]
- [http://msmvps.com/blogs/bill/archive/2004/06/23/8730.aspx A hacked Boolean]
- [http://msdn.microsoft.com/en-us/library/ms221627(v=VS.80).aspx VARIANT and VARIANTARG, MSDN Library]
- Programming with abstract data types, B Liskov, A Jones, ACM Sigplan Notices, 1974 
- Parallel processing and modular software construction, K. Jackson, Lecture Notes in Computer Science, 1977, Volume 54/1977, 436-443, doi:10.1007/BFb0021435 
- Encapsulated data types and generic procedures, Lecture Notes in Computer Science, 1977, Volume 54/1977, 171-214, doi:10.1007/BFb0021423