[Ethereum] Standard work-around for using a Solidity constant array (which is not supported) in pure function

arraysconstantpuresolidityview

I have an array in my contract like this and a pure method which uses it like this (simplified exmaple because my real exmaple is many more lines):

uint[16] constant x = [10, 2, 6, 42, 19, 5, 4, 36, 6, 6, 5, 5, 5, 46, 4, 4];

function foo(uint i, uint j) external pure returns (uint) {
    return x[i] + x[j] * 12;
}

But solidity doesn't seem to support this, so I can only figure out to change it to non constant, but then I'm foreced to switch to view even though my function is pure.

uint[16] x = [10, 2, 6, 42, 19, 5, 4, 36, 6, 6, 5, 5, 5, 46, 4, 4];

function foo(uint i, uint j) external view returns (uint) {
    return x[i] + x[j] * 12;
}

it seems I can only keep the funciton pure if I changd it in to a bunch of seperate uint insted of uint[16] but that's messy.

Is there a workaorund which keeps my function pure? Is just making it view the standard work-around to this?

Best Answer

It seems that is an pending feature https://github.com/ethereum/solidity/issues/1772

However, if the desired range is from 0-255, there is a trick for you.

bytes public constant TEST_MAP = hex"000804";
   
function test(uint8 key) external pure returns (byte) {
   return TEST_MAP[uint256(key)];
}

Related Solutions

solidity – Should External Non-Pure Functions Have Return Values?

An external function with mutability that is not view or pure (i.e. it is payable or non-payable) may or may not have a returns. This is an example of one that does, from UniswapV1:

function ethToTokenSwapInput(uint256 min_tokens, uint256 deadline)
    external
    payable
    returns (uint256 tokens_bought);

You send it an amount of ETH and specify the minimum amount of ERC-20 tokens to buy with those ETH, and it updates the blockchain state to reflect the new token and Ether balances after the swap, it emits a TokenPurchase event (that has a tokens_bought field), and it also returns the tokens_bought as a return value.

It this particular case, since the exact amount of tokens your ETH will buy you will depends on the market conditions at the moment of the swap, it is useful to be able to know tokens_bought, the exact number of tokens you actually ended up with after the swap.

If you’re calling this function from an externally-owned account (from “outside”, from a “normal” non-contract account, which you control with a private key), you will not have access to the return value, but you can read tokens_bought from the emitted TokenPurchase event.

If on the other hand you’re buying these tokens with ETH on Uniswap from within a contract, the contract will not be able to see the TokenPurchase event, but it will receive the amount of tokens bought via the return value, and can then go on to do something useful with it.

So if your function will be called from a contract, and you would like your function to do an action and then return to the calling contract some value resulting from that action, then declare returns, otherwise there is no need to.

Solidity – Solving ‘Function Cannot Be Declared as View Due to Potential State Modification’

There are a few different perspectives into this. Let's see.

Blockchain's perspective

The blockchain basically just stores data. Data can be read from any node. State changes aren't free, reading data from a node is free. The blockchain doesn't know if someone reads data locally from a node - it only cares if someone issues a transaction to change the blockchain state, and that costs.

Tooling

Tooling around the blockchain provide different ways of calling contracts' functionality. Modifying the blockchain state always requires a real transaction. But it's also fine to issue a static call to non-view functions - in that case the wannabe-transaction is issued only to your local node (or whichever node provider you use) and the state changes it performs are not persisted - but its operations are free.

One issue with tooling is that it typically relies on various 'hints' about how to call different functionality. For example if you want to call a non-view function, tooling typically offers you to issue a real transaction.

Most tooling (for example ethers.js) offer ways to call whichever function with whichever type - a local/static call or with a real transaction. It just may not be the most straightforward way, since the tooling tries to make things easy for you (by assuming you always want a real transaction to a non-view function).

Wallets

These are often quite dumbed-down versions of tooling, but a lot more user friendly. It may be difficult, if not impossible, to configure your wallet to issue a read-only call to a non-view function, for example. This of course applies only to functionality which is not triggered by various tooling (for example by a website running ethers.js).

Conclusion

In theory it's fully up to the caller whether to issue a real transaction or a local read-only call. In reality it depends on the used tools, whether they support that and only provide what they think you want.

Best Answer

Related Solutions

solidity – Should External Non-Pure Functions Have Return Values?

Solidity – Solving ‘Function Cannot Be Declared as View Due to Potential State Modification’

Related Topic