From c126724e564d39bfcd2f65df0b6d4a1903c4e7e8 Mon Sep 17 00:00:00 2001 From: William Entriken Date: Tue, 3 Dec 2019 21:01:48 -0500 Subject: [PATCH] Clarify new fallback function introduction --- docs/060-breaking-changes.rst | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/docs/060-breaking-changes.rst b/docs/060-breaking-changes.rst index 7c1753cc0..a0b1e76e7 100644 --- a/docs/060-breaking-changes.rst +++ b/docs/060-breaking-changes.rst @@ -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)``.