Understanding and Using the Delete Keyword in Solidity

solidity

The blockchain is an immutable, append-only transaction set.
I have the following questions regarding delete keyword –

Then what is the purpose of deletekeyword in solidity?

Is it only for variables stored in memory?

Is it possible to delete variables stored in storage and stack?

What are all the possible cases in which delete keyword should be used and where it should not be?

Best Answer

delete is actually not really deletion at all - it's only assigning a default value back to variables. It does not make difference whether the variable is in memory or in storage.

For example, issuing a delete to a uint variable simply sets the variable's value to 0.

delete will also give a bit of your used gas back - this is to encourage deleting variables after their data is no longer needed so the size of the blockchain would stay a bit smaller. Note that you can never regain more gas than what your current transaction is using.

You can read more about delete here: https://solidity.readthedocs.io/en/v0.4.24/types.html#delete

Related Solutions

Solidity Memory Keyword – What Does ‘Memory’ Do Exactly?

The Solidity FAQ on "memory" is highly recommended reading in entirety, and a snippet is provided below.

The Ethereum Virtual Machine has three areas where it can store items.

The first is “storage”, where all the contract state variables reside. Every contract has its own storage and it is persistent between function calls and quite expensive to use.

The second is “memory”, this is used to hold temporary values. It is erased between (external) function calls and is cheaper to use.

The third one is the stack, which is used to hold small local variables. It is almost free to use, but can only hold a limited amount of values.

For almost all types, you cannot specify where they should be stored, because they are copied everytime they are used.

The types where the so-called storage location is important are structs and arrays. If you e.g. pass such variables in function calls, their data is not copied if it can stay in memory or stay in storage. This means that you can modify their content in the called function and these modifications will still be visible in the caller.

There are defaults for the storage location depending on which type of variable it concerns (source):
state variables are always in storage
function arguments are always in memory
local variables of struct, array or mapping type reference storage by default
local variables of value type (i.e. neither array, nor struct nor mapping) are stored in the stack

The FAQ has code samples to help explain further.

A common mistake is to declare a local variable (of struct, array or mapping) and assume that it will be created in memory, although it will be created in storage.

The subtleties explanation of memory explains gas costs for using memory, which is a byte-array that "starts off zero-size, but can be expanded in 32-byte chunks by simply accessing or storing memory at indices greater than its current size".

Solidity – Understanding Memory, Storage, and Stack Areas in EVM

Storage

Let's consider storage first. Storage is extremely expensive. It costs 20000 gas to set a storage location from zero to a value, and 5000 gas to change its value. (You do get some gas back for resetting a location to 0.) The reason is that a contract's storage values are stored on the blockchain forever which has a real-world cost. It's also 200 gas to read a word, compared with 3 for memory.

So for storage, use it only when you really must.

When must you use storage? For values that have to be persisted between different contract calls. For example the balances of accounts for an ERC20 token. Storage updates are state updates of your contract and are not really for temporary data. Storage of one contract can also be read by another contract, or by querying the blockchain without running the contract.

You can think of it like hard disk/SSD, if you like. Storage retains its value when the computer's not running.

Memory

Memory is relatively much cheaper than storage. It costs 3 gas to read or write a word, plus some gas if you are expanding memory. For a few KB it's very cheap indeed, but the cost goes up quadratically the more you use: a megabyte of memory will cost a couple of million gas.

However, the memory is only accessible during contract execution; once execution is finished, its contents are discarded.

When should you use memory? Pretty much for everything non-permanent. It's the general workhorse.

You can think of it like a computer's RAM. It vanishes when the computer is not running.

Stack

The costs of storing data on the stack are similar to those for memory. Sometimes there will be less overhead from having to push memory addresses to the stack; sometimes there will be more overhead as the compiler has to shuffle things around on the stack. The stack has a maximum capacity of 1024 items, but only the top 16 are easily accessible. If you run out of stack then contract execution will fail. The compiler generally uses it for intermediate values in computations and other scratch quantities.

On the whole, I'd leave the stack to the compiler to work out.

The stack also does not persist after contract termination.

All the info above is buried in the Yellow Paper - I've read it so you don't have to :-)