[Tut] Solidity Contract Types, Byte Arrays, and {Address, Int, Rational} Literals

[Tut] Solidity Contract Types, Byte Arrays, and {Address, Int, Rational} Literals - Printable Version

+- Sick Gaming (https://sickgaming.net)
+-- Forum: Programming (https://sickgaming.net/forum-76.html)
+--- Forum: Python (https://sickgaming.net/forum-83.html)
+--- Thread: [Tut] Solidity Contract Types, Byte Arrays, and {Address, Int, Rational} Literals (/thread-100027.html)

[Tut] Solidity Contract Types, Byte Arrays, and {Address, Int, Rational} Literals - xSicKxBot - 10-05-2022

Solidity Contract Types, Byte Arrays, and {Address, Int, Rational} Literals

5/5 – (1 vote)

[Image: lyteCache.php?origThumbUrl=https%3A%2F%2...efault.jpg]

With this article, we continue our journey through the realm of Solidity data types following today’s topics:

contract types,
fixed-size byte arrays,
dynamically-sized byte arrays,
address literals,
rational, and
integer literals.

It’s part of our long-standing tradition to make this (and other) articles a faithful companion or a supplement to the official Solidity documentation.

Download PDF Slide Deck at the end of this tutorial!

Contract Types

[Image: image-37-1024x576.png]

To quote the official Solidity documentation, “every contract defines its own type”.

This statement might seem a bit cryptic, and since we’re an efficient crowd, we’d surely like to know what it means.

We can all remember that some number of articles ago, we mentioned how Solidity has key elements of an object-oriented programming language (OOPL). We also emphasized how smart contracts in Solidity are very similar to classes in an OOPL.

Classes themselves are a mesh of custom data types, i.e. structs, and functions, which qualifies classes to be treated as types.

By extension, our contracts are also treated as types, and as every contract is unique in its own right, it defines its own type. Being a type, we can implicitly convert a specific contract to a contract it inherits from, i.e. if contract “Aa” inherits from contract A, it can also be converted to contract “A”.

[Image: image-38-1024x768.png]

Besides that, we can explicitly convert each contract to and from the address type. Even more, we can conditionally convert a contract to and from the

Code:
address payable

type (remember, that’s the same type as the

Code:
address

type, but predetermined to receive Ether).

The condition is that the contract type must have a

Code:
receive

Code:
payable

fallback function. If it does, we can make the conversion to address payable by using

Code:
address(x)

.

However, if the contract type does not implement (a more professional way to say “have”) a

Code:
receive

Code:
payable

fallback function, then the conversion to address payable has to be even more explicit (no swearing!) by stating

Code:
payable(address(x))

.

A local variable

Code:
obc

of a contract type

Code:
OurBeautifulContract

is declared by

Code:
OurBeautifulContract obc;

.

Once we point our variable

Code:
obc

to an instantiated (newly created) contract, we’d be able to call functions on that contract.

In terms of its data representation, a contract is identical to the

Code:
address

type. This is important because the contract type is not directly supported by the ABI, but the address type, as its representative, is supported by the ABI.

In contrast to the types mentioned so far, contract types don’t support any operators.

The members of contract types are the external functions (the functions only available to other contracts) and state variables whose visibility is set to

Code:
public

.

When we need to access type information about the contract, like the

Code:
OurBeautifulContract

above, we’d call the

Code:
type(OurBeautifulContract)

function (docs).

Fixed-Size Byte Arrays

[Image: image-39-1024x682.png]

The value type

Code:
bytesN

holds a sequence of bytes, whose length, and accordingly

Code:
N

goes from 1 to up to 32, i.e.,

Code:
bytes1

, …,

Code:
bytes32

.

The available operators for fixed-size operators are:

Comparisons:
Code:
<=, <, ==, !=, >=, >
(evaluate to bool)
Bit operators:
Code:
&, |, ^
(bitwise exclusive or),
Code:
~
(bitwise negation)
Shift operators:
Code:
<<
(left shift),
Code:
>>
(right shift)
Index access: If
Code:
x
is of type
Code:
bytesN
, then
Code:
x[k]
for
Code:
0 <= k < N
returns the
Code:
k
-th byte (read-only). In other words,
Code:
x[0]
up to (inclusive)
Code:
x[N-1]
is available for index access; if
Code:
N = 1
, then only
Code:
x
is of type
Code:
bytes1
, and
Code:
x[0]
is the only element, i.e. byte accessible by the index.

The shifting operator always uses an unsigned integer type as a right operand, which represents the number of bits to shift by, and returns the type of the left operand.

Let’s take a look at a simple example to illustrate:

Code:
bytes2 lo = 0x1234; // (lo is the left operand)
uint8 ro = 5; // (ro is the right operand variable, must be u... type)
lo << ro // will evaluate to an lo type, bytes2

A fixed-size byte array has only one member, .length, that holds the fixed length of the byte array. This member is accessible as the read-only value.

Warning: Since the type

Code:
bytes1

is a sequence of 1 byte in length, the type

Code:
bytes1[]

is a fixed-size byte array of 1-byte sequences. However, each element of the array is padded with 31 bytes, due to padding rules for elements stored in memory, stack, and call data, i.e., except in storage. Therefore, according to the official Solidity documentation, it’s better to use

Code:
bytes

type instead of

Code:
bytes1[]

Note: Value types in storage are packed/compacted together and share a storage slot, taking only as much space per value type as really needed. In contrast, the stack, memory, and

Code:
calldata

pad value types and store in separate slots, meaning that each variable uses a whole slot of 32 bytes, even if the value type is shorter than 32 bytes, effectively wasting the memory space.

Before Solidity v0.8.0, the keyword

Code:
byte

was an alias for

Code:
bytes1

.

Dynamically-Sized Byte Arrays

[Image: image-40-1024x680.png]

There are two dynamically-sized non-value types, namely

Code:
bytes

and

Code:
string

Code:
bytes
is a dynamically-sized byte array, while
Code:
string
is a dynamically-sized UTF-8-encoded string.

Address Literals

Address literals are hexadecimal literals that pass the address checksum test, e.g.

Code:
0xdCad3a6d3569DF655070DEd06cb7A1b2Ccd1D3AF

.

Hexadecimal literals will produce an error if they are between 39 and 41 digits long and do not pass the checksum test.

However, we can remove the error by prepending zeros to integer types or appending zeros to

Code:
bytesNN

types.

The Ethereum Improvement Proposal EIP-55 defines the mixed-case address checksum.

Integer and Rational Literals

Integer Literals

Integer literals are created using a sequence of digits from a range 0-9, and each digit is interpreted (weighted) based on its position in the sequence.

Multiplied by an exponent of 10, e.g. 217 is interpreted as two hundred and seventeen, because, reading from right to left, we have 7 * 100 + 1 * 101 + 2 * 102.

A reminder, 100 = 1.

Octal literals don’t exist in Solidity and leading zeros are invalid.

Decimal Fractional Literals

Decimal fractional literals consist of a dot

Code:
.

(or, depending on the locale) and at least one number on either of the sides, e.g.

Code:
1.

Code:
.1

, and

Code:
1.3

Info: “A locale consists of a number of categories for which country-dependent formatting or other specifications exist” (sou rce).

Scientific Notation

Solidity also supports scientific notation in the form of 2e10, where 2 (left of “e”) is called mantissa (M) and the exponent (E) must be an integer. In a general form, we would write it as MeE and it is interpreted as M * 10**E, e.g. 2e10, -2e10, 2e-10, 2.5e1.

Readable Underscore Notation

[Image: image-41.png]

We can also do a neat thing: separate the digits of a numeric literal for easier readability, such as in decimal

Code:
123_000

, hexadecimal

Code:
0x2eff_abde

, scientific decimal notation

Code:
1_2e345_678

.

However, there are no leading, trailing, or multiple underscores; they can only be added between two digits.

Number Literal Expressions

Expressions containing number literals preserve their precision until they are converted to a non-literal type.

Such a conversion means an explicit conversion, or that the number literals are used with something else than a number literal expression, like boolean literals.

This behavior implies that computations don’t overflow and divisions don’t truncate in number literal expressions.

A very good example would be a number literal expression (2**800 + 1) – 2**800, which results in the constant 1 (of type

Code:
uint8

), although the intermediate results would not fit the capacity of the EVM word length of 32 bytes.

One more example shows that an integer 4 is produced by computing the expression

Code:
.5 * 8

, although the intermediary results are not integers.

More Operations

Warning: most operators produce a literal expression when applied to number literals, but there are also two exceptions:

Ternary operator
Code:
(... ? ... : ...)
,
Array subscript (
Code:
<array>[<index>]
).

In other words, expressions like

Code:
255 + (true ? 1 : 0)

Code:
255 + [1, 2, 3][0]

are not equivalent to using the literal 256 (the result of these two expressions), as they are computed within the type

Code:
uint8

and can lead to an overflow.

Number literal expressions can use the same operators as the integers, but both operands must compute yield an integer.

If either of the operands is fractional, bit operations are inapplicable for use;
If the exponent is a decimal fractional literal, the exponentiation operation is also inapplicable for use.

Shifts and exponentiation

Code:
*

operations with literal numbers in place of a left

Code:
(base*

) operand and integer types in place of the right (

Code:
exponent*

) operand are performed in the

Code:
uint256

for non-negative literals or

Code:
int256

for negative literals (a

Code:
*

symbol pertains to the exponentiation operations context).

Warning: Since Solidity v0.4.0 division on integer literals produces a rational number, e.g. 7 / 2 = 3.5.

Solidity has a number literal types for each rational number, e.g. integer literals and rational number literals belong to the same number literal type.

All number literal expressions (expressions with only number literals and operators) also belong to number literal types, e.g. 1 + 2 and 2 + 1 belong to the same number literal type.

Note: When number literal types are used with non-literal expressions, they are converted into a non-literal type, e.g.

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

Here, 1 is converted into a non-literal type

Code:
uint128

, i.e. variable

Code:
a

, but a common type for both

Code:
2.5

and

Code:
uint128

doesn’t exist and the compiler will reject the code.

Conclusion

In this article, we added even more data types in Solidity under our proverbial belt!

First, we introduced and learned about the contract type.
Second, we fixed our understanding of the fixed-size byte array type.
Third, the situation got dynamic by studying the dynamically-sized byte array type.
Fourth, we addressed the… what was it called… Aha – address literals!
Fifth, we came to the most rational decision and discovered what rational and integer literals are and, of course, how can they be put to good use.

Slide Deck Data Types

You can scroll through the data types discussed in this tutorial here:

Solidity-Overview-Data-Types-More Download