cerc-io/solidity
15
0
Fork 0
mirror of https://github.com/ethereum/solidity synced 2023-10-03 13:03:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Clarify new fallback function introduction

Browse Source
This commit is contained in:
William Entriken 2019-12-03 21:01:48 -05:00 committed by chriseth
parent 34863583ed
commit c126724e56
1 changed files with 10 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/060-breaking-changes.rst
View File

@ -61,12 +61,16 @@ This section highlights changes that affect syntax and semantics.
* The unnamed function commonly referred to as "fallback function" was split up into a new
fallback function that is defined using the ``fallback`` keyword and a receive ether function
defined using the ``receive`` keyword. If present, the receive ether function is called
whenever the call data is empty. The new fallback function is called when no
other function matches. It can be payable in which case it may accept value
or non-payable in which case transactions not matching any other function
which send value will revert. If you only implement the receive and not the fallback function, calling a non-existing function on your contract will now revert. You should only need to implement the fallback function
if you are following an upgrade or proxy pattern.
defined using the ``receive`` keyword.
* If present, the receive ether function is called whenever the call data is empty (whether
or not ether is received). This function is implicitly ``payable``.
* The new fallback function is called when no other function matches (if the receive ether
function does not exist then this includes calls with empty call data).
You can make this function ``payable`` or not. If it is not ``payable`` then transactions
not matching any other function which send value will revert. You should only need to
implement the new fallback function if you are following an upgrade or proxy pattern.
* Functions can now only be overridden when they are either marked with the ``virtual`` keyword or defined in an interface. When overriding a function or modifier, the new keyword ``override`` must be used. When overriding a function or modifier defined in multiple parallel bases, all bases must be listed in parentheses after the keyword like so: ``override(Base1, Base2)``.