Elementary Types

These are basic types that can be used in Solidity:

1. uint<M>: Represents an unsigned integer of M bits. M has to be between 0 and 256 and must be divisible by 8. For example, uint8, uint32, and uint256.

2. int<M>: Represents a signed integer (using two’s complement) of M bits. Like uint, M has to be divisible by 8.

3. address: Think of this as an Ethereum address. It's equivalent to uint160 but is specifically interpreted as an address of an account or contract.

4. uint and int: These are just shorthand for uint256 and int256 respectively.

5. bool: Represents a boolean value. It's equivalent to uint8, but restricted to 0 (false) and 1 (true).

6. fixed<M>x<N>: Represents a fixed-point decimal number. The number has M bits in total and N denotes the value v as v / (10 ** N). This allows representation of numbers like 10.5 or 12.3 in the blockchain.

7. ufixed<M>x<N>: It's the unsigned version of fixed<M>x<N>.

8. fixed and ufixed: Shorthands for fixed128x18 and ufixed128x18 respectively.

9. bytes<M>: Represents a sequence of M bytes. M must be between 0 and 32.

10. function: Represents a combination of an Ethereum address and a function selector. It's like a reference to a function in a specific contract.

Array Type

1. <type>[M]: Represents a fixed-size array with M elements of the specified type. Note that while the ABI can describe zero-length arrays, the Solidity compiler doesn't support them.

Dynamic Types

1. bytes: Represents a dynamic-sized sequence of bytes. The size isn't fixed, and it grows as you add more bytes.

2. string: Represents a dynamic-sized string. It's assumed to be UTF-8 encoded.

3. <type>[]: Represents a dynamic-sized array of the given type. For instance, uint[] would be an array of unsigned integers, but the number of integers isn't fixed.

Tuple

1. (T1,T2,...,Tn): Represents a tuple containing types T1 through Tn. For instance, (uint256, address) would be a tuple containing an unsigned integer and an address.

The ABI types give flexibility in encoding different kinds of data for contract interaction. The distinction between static types (like uint8) and dynamic types (like string or bytes) is essential because it affects how the data is encoded when sent to or from a contract.

The Ethereum ABI (Application Binary Interface) serves as the standard way for encoding and decoding data to and from the blockchain, especially when interacting with smart contracts. However, Solidity, as a language, has some types that are not part of the ABI and vice versa.

The list below maps specific Solidity types to their corresponding ABI types:

1. address payable:

   • Solidity: A specific address type that can receive Ether via transfers.

   • ABI: Simply mapped to address. This distinction of "payable" is important in Solidity for ensuring safety but does not need to be part of the ABI encoding.

2. contract:

   • Solidity: Represents a user-defined contract.

   • ABI: Mapped to address because in the context of the ABI, a contract is essentially just an Ethereum address.

3. enum:

   • Solidity: Enumerated types (a way to define a type that can have one of several predefined values).

   • ABI: Mapped to uint8 which represents the index of the enum value. This means each of the enumerated values is assigned a unique integer, starting from 0.

   Note: Before Solidity 0.8.0, enums could have more than 256 members, so they were represented by the smallest integer type capable of holding any member value. For example, if an enum had 300 members, it would be too big for uint8 but would fit in uint16.

4. user defined value types:

   • Solidity: Custom defined types based on existing types. Introduced in Solidity 0.8.8.

   • ABI: The ABI will use the underlying type to represent this. For instance, if a user defines a type type MyInt is int256, in the ABI, it would just be an int256.

5. struct:

   • Solidity: A composite type that groups together variables of other types.

   • ABI: Mapped to tuple. The tuple in the ABI is a way to encode a list of types. This maps well to the struct in Solidity which is essentially a collection of different variables of potentially different types.