There is more too this than meets the eye.
First, there is no way to truly delete since the transaction that created the element and the previous states of the chain will forever remain part of immutible history.
Second, although it will help reduce chain bloat by marking the storage as useless (in the present state), the delete operation is in fact unavoidably a write to the state which costs gas to execute.
Third, logically deleting an element doesn't reorganize the list. It merely creates a void in the midst of the list, roughly like [a,b,c, nothing, e,f,g]. This _might) create logical problems in or around the contract.
A reorganization is possible in the case of an unordered list. This is done by moving the last element in the list into the slot to delete and then reducing the length of the array. This only works with "unordered" lists because it relies on shuffling the order of the elements. https://medium.com/@robhitchens/solidity-crud-part-2-ed8d8b4f74ec
You may find that either leaving the elements in place or reorganizing around mappings is actually a better data structure. You can also consider a soft delete which admittedly does nothing to reduce chain bloat.
Have a look over here for a mapped struct with delete
pattern. Are there well-solved and simple storage patterns for Solidity?
Hope it helps.
UPDATE:
Thanks, smarx, for jumping in. Now, I'm curious!
Is it wrong to think delete
is always a net costly operation?
pragma solidity ^0.4.20;
contract Refunds {
mapping(uint => bool) public data;
function setIt() public {
data[1] = true;
}
function deleteIt() public { // net cost ~ 5000 gas
delete data[1];
}
}