You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This VIP proposes to completely remove the @payable and @nonpayable decorators from the language syntax.
Motivation
We live in a world where native currency transfers are less and less used compared to ERC20s.
People ended up saving gas by using the @payable decorator just to remove the runtime check that a @nonpayable modifier implies.
The compiler is smart enough to know when a function is payable.
This change reduces the cognitive overhead of using native currency transfers for developers.
Specification
@payable and @nonpayable should be disallowed in the syntax.
When a function accesses msg.value the abi of the function should be payable, otherwise it's always non-payable.
The runtime check to make sure that a function is non-payable is turned into a no-op.
Backwards Compatibility
This is a breaking change that requires changes in existing codebases. This VIP can be implemented without waiting for a major release by turning the @nonpayable modifier into a no-op, which is already the case for @payable and showing a deprecation warning.
I personally don't think it's a general blocker, but I want to highlight that in the EIP-721 standard we have the following specifications:
function safeTransferFrom(address_from, address_to, uint256_tokenId, bytesdata) externalpayable;
function safeTransferFrom(address_from, address_to, uint256_tokenId) externalpayable;
function transferFrom(address_from, address_to, uint256_tokenId) externalpayable;
function approve(address_approved, uint256_tokenId) externalpayable;
In probably 99% of the implementations, these functions do not access msg.value but would require to be payable at the ABI level. The current proposal would lead to an inconsistent ABI for EIP-721 token implementations. We could add maybe a kwarg to the function parameters, is_payable = True to enforce it:
Simple Summary
This VIP proposes to completely remove the
@payable
and@nonpayable
decorators from the language syntax.Motivation
@payable
decorator just to remove the runtime check that a@nonpayable
modifier implies.Specification
@payable
and@nonpayable
should be disallowed in the syntax.msg.value
the abi of the function should bepayable
, otherwise it's always non-payable.Backwards Compatibility
This is a breaking change that requires changes in existing codebases. This VIP can be implemented without waiting for a major release by turning the
@nonpayable
modifier into a no-op, which is already the case for@payable
and showing a deprecation warning.Copyright
Copyright and related rights waived via CC0
The text was updated successfully, but these errors were encountered: