Lists and Records

Line 41 is the first function, and it takes one parameter: `Call[] calldata calls`. Function first: many values of a single type, numbered from zero, with a length the code can ask for. The name: an array.

Two brackets do all of that work. `Call` is one record; `Call[]` is a list of them. How long the list runs is decided nowhere in this file. The caller decides, at the moment of the call, and line 43 simply asks the list itself with `calls.length`.

One more word on line 41, sitting between the type and the name. Function first: a marker saying this value is part of the incoming call data, readable but never writable, and not copied anywhere before you read it. The name: calldata.

Now compare line 44, three lines down, where `returnData` is built fresh as `bytes[] memory`. Two words for two different places a value can live during one call: the input exactly as it arrived, and workspace created on the spot.

Line 46 opens with `for`. Function first: an instruction to run a block of code again and again, once for each entry in a list, with a counter that says which entry is being handled. The name: a loop.

Read the header. Start at `i = 0`, keep going while `i < length`. The third slot, where the step usually goes, is empty here, and line 51 does that job inside the body instead. Loops are rare in contract code, and this file is the exception that shows why.

Here is why loops are rare. Every repetition costs, and the number of repetitions is chosen by whoever calls, so the price of one call to line 41 is not a fixed figure at all. It moves with the length of the list handed in.

Inside, five lines. Line 47 makes a fresh `bool` on every pass, line 51 waits until the next step. The three in between are the whole of what this contract does. Tap them.

Function first: a marker wrapped around a piece of arithmetic saying do not add the automatic range check to this. The name: unchecked. Since version 0.8, which line 2 pins exactly, every addition and subtraction is checked and refuses to wrap around.

Line 51 steps the counter with that check switched off. The counter stops at `length`, which is the length of an array, so the check could never fire and paying for it on every pass buys nothing. Line 202 does the same thing to a subtraction.

The last of the aggregate functions adds up an amount from every entry. Line 130 opens a running total at zero, line 137 reads one entry's value out of its record, line 140 adds it in, and line 160 compares the total against what was actually sent.

Line 140 is `unchecked` too, and this time the author left the reasoning in the file, on lines 138 and 139. That is what an unchecked block always is: a claim that the numbers cannot reach the edge, with the argument either written down or left out.

Line 60 returns `Result[] memory returnData`: an array of the record declared on line 32, one entry per call made. Line 62 builds it with `new` at exactly the caller's length, and line 65 takes a handle on entry `i`, so writing through `result` on line 67 writes into the array.

Two functions put something else between their call and their counter, on lines 106 to 120 and again on 142 to 156. That is assembly, a lower level language this course reaches much later. For now, read the comment on line 107: it says in English what the block does.

The bottom third of the file is ten functions, each doing one line of work, each marked `view`. They are there so a batch can ask about the block it is running inside: its number, its hash, its time, the chain id, the coinbase, the gas limit, the base fee.

Line 191 is the one you will meet most often: `block.timestamp`, the time stamped on the current block. None of these is stored in this contract, which is how a file with no state block still has ten things to tell you about the world.

Every line is lit. Four structs, sixteen functions, two blocks of assembly and roughly sixty lines of comment. Not one stored value anywhere in it, and yet the file runs longer than either of the tokens you read last week.

Five words carried the middle third: struct, array, calldata, loop, unchecked. Now be exact about what the first two of them settle, and about what they quietly leave open.

Act two is the vocabulary, and you have five more of it. A struct names a record. An array holds many of one thing. `calldata` says the input is read where it lies. A loop repeats. `unchecked` drops a range check the compiler would otherwise add.

All five arrived inside working code, on a contract that sits at one address on more than a hundred chains and keeps nothing at all. Look for them in the next file you open: once you can see them, they are everywhere.