Solidity is a statically typed language, which means that the type of each variable (state and local) needs to be specified. Solidity provides several elementary types which can be combined to form complex types.

In addition, types can interact with each other in expressions containing operators. For a quick reference of the various operators, see Order of Precedence of Operators.

The concept of “undefined” or “null” values does not exist in Solidity, but newly declared variables always have a default value dependent on its type. To handle any unexpected values, you should use the revert function to revert the whole transaction, or return a tuple with a second bool value denoting success.

bool : The possible values are constants true and false.

Operators:

• ! (logical negation)
• && (logical conjunction, “and”)
• || (logical disjunction, “or”)
• == (equality)
• != (inequality)

The operators || and && apply the common short-circuiting rules.
This means that in the expression f(x) || g(y), if f(x) evaluates to true, g(y) will not be evaluated even if it may have side-effects.

int / uint : Signed and unsigned integers of various sizes.
Keywords uint8 to uint256 in steps of 8 (unsigned of 8 up to 256 bits) and int8 to int256. uint and int are aliases for uint256 and int256, respectively.

Operators:

• Comparisons: <=, <, ==, !=, >=, > (evaluate to bool)
• Bit operators: &, |, ^ (bitwise exclusive or), ~ (bitwise negation)
• Shift operators: << (left shift), >> (right shift)
• Arithmetic operators: +, -, unary - (only for signed integers), *, /, % (modulo), ** (exponentiation)

For an integer type X, you can use type(X).min and type(X).max to access the minimum and maximum value representable by the type.

The result of a shift operation has the type of the left operand, truncating the result to match the type.
The right operand must be of unsigned type, trying to shift by a signed type will produce a compilation error.

Shifts can be “simulated” using multiplication by powers of two in the following way.
Note that the truncation to the type of the left operand is always performed at the end, but not mentioned explicitly.

• x << y is equivalent to the mathematical expression x * 2**y.
• x >> y is equivalent to the mathematical expression x / 2**y, rounded towards negative infinity.

Addition, subtraction and multiplication have the usual semantics, with two different modes in regard to over- and underflow:

By default, all arithmetic is checked for under- or overflow, but this can be disabled using the unchecked block, resulting in wrapping arithmetic. More details can be found in that section.

The expression -x is equivalent to (T(0) - x) where T is the type of x.
It can only be applied to signed types.
The value of -x can be positive if x is negative.
There is another caveat also resulting from two’s complement representation:

If you have int x = type(int).min;, then -x does not fit the positive range.
This means that unchecked { assert(-x == x); } works, and the expression -x when used in checked mode will result in a failing assertion.

Since the type of the result of an operation is always the type of one of the operands, division on integers always results in an integer.
In Solidity, division rounds towards zero.
This means that int256(-5) / int256(2) == int256(-2).

Note that in contrast, division on literals results in fractional values of arbitrary precision.

The modulo operation a % n yields the remainder r after the division of the operand a by the operand n, where q = int(a / n) and r = a - (n * q).
This means that modulo results in the same sign as its left operand (or zero) and a % n == -(-a % n) holds for negative a:

• int256(5) % int256(2) == int256(1)
• int256(5) % int256(-2) == int256(1)
• int256(-5) % int256(2) == int256(-1)
• int256(-5) % int256(-2) == int256(-1)

Exponentiation is only available for unsigned types in the exponent.
The resulting type of an exponentiation is always equal to the type of the base.
Please take care that it is large enough to hold the result and prepare for potential assertion failures or wrapping behaviour.

fixed / ufixed: Signed and unsigned fixed point number of various sizes.
Keywords ufixedMxN and fixedMxN, where M represents the number of bits taken by the type and N represents how many decimal points are available.
M must be divisible by 8 and goes from 8 to 256 bits.
N must be between 0 and 80, inclusive.
ufixed and fixed are aliases for ufixed128x18 and fixed128x18, respectively.

Operators:

• Comparisons: <=, <, ==, !=, >=, > (evaluate to bool)
• Arithmetic operators: +, -, unary -, *, /, % (modulo)

The address type comes in two flavours, which are largely identical:

• address: Holds a 20 byte value (size of an Ethereum address).
• address payable: Same as address, but with the additional members transfer and send.

The idea behind this distinction is that address payable is an address you can send Ether to, while you are not supposed to send Ether to a plain address, for example because it might be a smart contract that was not built to accept Ether.

Type conversions:

Implicit conversions from address payable to address are allowed, whereas conversions from address to address payable must be explicit via payable(<address>).

Explicit conversions to and from address are allowed for uint160, integer literals, bytes20 and contract types.

Only expressions of type address and contract-type can be converted to the type address payable via the explicit conversion payable(...).
For contract-type, this conversion is only allowed if the contract can receive Ether, i.e., the contract either has a receive or a payable fallback function.
Note that payable(0) is valid and is an exception to this rule.

Operators:

• <=, <, ==, !=, >= and >

For a quick reference of all members of address, see Members of Address Types.

• balance and transfer

It is possible to query the balance of an address using the property balance and to send Ether (in units of wei) to a payable address using the transfer function:

address payable x = payable(0x123);
address myAddress = address(this);
if (x.balance < 10 && myAddress.balance >= 10) x.transfer(10);

The transfer function fails if the balance of the current contract is not large enough or if the Ether transfer is rejected by the receiving account.
The transfer function reverts on failure.

• send

Send is the low-level counterpart of transfer.
If the execution fails, the current contract will not stop with an exception, but send will return false.

• call, delegatecall and staticcall

In order to interface with contracts that do not adhere to the ABI, or to get more direct control over the encoding, the functions call, delegatecall and staticcall are provided.
They all take a single bytes memory parameter and return the success condition (as a bool) and the returned data (bytes memory).
The functions abi.encode, abi.encodePacked, abi.encodeWithSelector and abi.encodeWithSignature can be used to encode structured data.

Example:

bytes memory payload = abi.encodeWithSignature("register(string)", "MyName");
(bool success, bytes memory returnData) = address(nameReg).call(payload);
require(success);

It is possible to adjust the supplied gas with the gas modifier:

address(nameReg).call{gas: 1000000}(abi.encodeWithSignature("register(string)", "MyName"));

Similarly, the supplied Ether value can be controlled too:

address(nameReg).call{value: 1 ether}(abi.encodeWithSignature("register(string)", "MyName"));

Lastly, these modifiers can be combined. Their order does not matter:

address(nameReg).call{gas: 1000000, value: 1 ether}(abi.encodeWithSignature("register(string)", "MyName"));

In a similar way, the function delegatecall can be used: the difference is that only the code of the given address is used, all other aspects (storage, balance, …) are taken from the current contract.
The purpose of delegatecall is to use library code which is stored in another contract.
The user has to ensure that the layout of storage in both contracts is suitable for delegatecall to be used.

Since byzantium staticcall can be used as well. This is basically the same as call, but will revert if the called function modifies the state in any way.

All three functions call, delegatecall and staticcall are very low-level functions and should only be used as a last resort as they break the type-safety of Solidity.

The gas option is available on all three methods, while the value option is only available on call.

• code and codehash

You can query the deployed code for any smart contract.
Use .code to get the EVM bytecode as a bytes memory, which might be empty.
Use .codehash to get the Keccak-256 hash of that code (as a bytes32).
Note that addr.codehash is cheaper than using keccak256(addr.code).

Every contract defines its own type.
You can implicitly convert contracts to contracts they inherit from.
Contracts can be explicitly converted to and from the address type.

Explicit conversion to and from the address payable type is only possible if the contract type has a receive or payable fallback function.
The conversion is still performed using address(x).
If the contract type does not have a receive or payable fallback function, the conversion to address payable can be done using payable(address(x)).
You can find more information in the section about the address type.

If you declare a local variable of contract type (MyContract c), you can call functions on that contract.
Take care to assign it from somewhere that is the same contract type.

You can also instantiate contracts (which means they are newly created). You can find more details in the ‘Contracts via new’ section.

The data representation of a contract is identical to that of the address type and this type is also used in the ABI.

Contracts do not support any operators.

The members of contract types are the external functions of the contract including any state variables marked as public.

For a contract C you can use type(C) to access type information about the contract.

The value types bytes1, bytes2, bytes3, …, bytes32 hold a sequence of bytes from one to up to 32.

Operators:

• Comparisons: <=, <, ==, !=, >=, > (evaluate to bool)
• Bit operators: &, |, ^ (bitwise exclusive or), ~ (bitwise negation)
• Shift operators: << (left shift), >> (right shift)
• Index access: If x is of type bytesI, then x[k] for 0 <= k < I returns the k th byte (read-only).

The shifting operator works with unsigned integer type as right operand (but returns the type of the left operand), which denotes the number of bits to shift by.
Shifting by a signed type will produce a compilation error.

Members:

• .length yields the fixed length of the byte array (read-only).

bytes:
Dynamically-sized byte array, see Arrays.
Not a value-type!

string:
Dynamically-sized UTF-8-encoded string, see Arrays.
Not a value-type!

Hexadecimal literals that pass the address checksum test, for example 0xdCad3a6d3569DF655070DEd06cb7A1b2Ccd1D3AF are of address type.
Hexadecimal literals that are between 39 and 41 digits long and do not pass the checksum test produce an error.
You can prepend (for integer types) or append (for bytesNN types) zeros to remove the error.

Integer literals are formed from a sequence of digits in the range 0-9.
They are interpreted as decimals.
For example, 69 means sixty nine.
Octal literals do not exist in Solidity and leading zeros are invalid.

Decimal fractional literals are formed by a . with at least one number after the decimal point. Examples include .1 and 1.3 (but not 1.).

Scientific notation in the form of 2e10 is also supported, where the mantissa can be fractional but the exponent has to be an integer.
The literal MeE is equivalent to M * 10**E.
Examples include 2e10, -2e10, 2e-10, 2.5e1.

Underscores can be used to separate the digits of a numeric literal to aid readability.
For example, decimal 123_000, hexadecimal 0x2eff_abde, scientific decimal notation 1_2e345_678 are all valid.
Underscores are only allowed between two digits and only one consecutive underscore is allowed.
There is no additional semantic meaning added to a number literal containing underscores, the underscores are ignored.

Number literal expressions retain arbitrary precision until they are converted to a non-literal type (i.e. by using them together with anything other than a number literal expression (like boolean literals) or by explicit conversion).
This means that computations do not overflow and divisions do not truncate in number literal expressions.

For example, (2**800 + 1) - 2**800 results in the constant 1 (of type uint8) although intermediate results would not even fit the machine word size.
Furthermore, .5 * 8 results in the integer 4 (although non-integers were used in between).

Any operator that can be applied to integers can also be applied to number literal expressions as long as the operands are integers.
If any of the two is fractional, bit operations are disallowed and exponentiation is disallowed if the exponent is fractional (because that might result in a non-rational number).

Shifts and exponentiation with literal numbers as left (or base) operand and integer types as the right (exponent) operand are always performed in the uint256 (for non-negative literals) or int256 (for a negative literals) type, regardless of the type of the right (exponent) operand.

uint128 a = 1;
uint128 b = 2.5 + a + 0.5;