3

I just realized that "external" keyword in a function declaration will cost less gas than "public" even if it can be only called from outside the contract.

why not use that in the ERC20 token?

Indeed the token doesn't have to use its functions itself.

| improve this question | | | | |
3

Yes, comparing public and external keywords, the external keyword will consume lesser gas than public keyword.

The difference is because, in public functions, Solidity immediately copies array arguments to memory, while external functions can read directly from call data. Memory allocation is expensive, whereas reading from call data is cheap.

The reason that public functions need to write all of the arguments to memory is that public functions may be called internally, which is actually an entirely different process than external calls. Internal calls are executed via jumps in the code, and array arguments are passed internally by pointers to memory. Thus, when the compiler generates the code for an internal function, that function expects its arguments to be located in memory.

For external functions, the compiler doesn't need to allow internal calls, and so it allows arguments to be read directly from call data, saving the copying step.

As for best practices, you should use external if you expect that the function will only ever be called externally, and use public if you need to call the function internally. It almost never makes sense to use the this.f() pattern, as this requires a real CALL to be executed, which is expensive. Also, passing arrays via this method would be far more expensive than passing them internally.

You will essentially see performance benefits with external any time you are only calling a function externally, and be passing in large arrays.

| improve this answer | | | | |
0

External functions cannot be overridden in derived contracts.

| improve this answer | | | | |
  • This is not correct you can override external functions from inherited contracts. – Ismael Jan 15 '19 at 20:03
  • This was only introduced in Solidity 0.5.1 I think -- I'm still on 0.4.20, and I spent an hour trying to figure out why it didn't work. – ulu Jan 16 '19 at 8:55
  • I've tried with 0.4.1, 0.4.18, 0.4.20 and it does work as expected, perhaps it is a combination with other bug. However it was never mean that external cannot be overriden. – Ismael Jan 16 '19 at 16:10
  • 1
    If you look at github.com/ethereum/solidity/releases/tag/v0.5.1, it says it in "Language features" -- "Allow public functions to override external functions." Perhaps you could override external with external, and I used public? I don't remember.. – ulu Jan 16 '19 at 16:51
  • With 0.4.xx solc generates an error if you try to override an external with public. – Ismael Jan 16 '19 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.