Solidity Function Types conversion

Language Design
1

In docs-soliditylang-org-en-v0.8.21.pdf, p65
A function type A is implicitly convertible to a function type B if and only if their parameter types are identical, their return types are identical, their internal/external property is identical and 1. the state mutability of A is more restrictive than the state mutability of B
. In particular:
• pure functions can be converted to view and non-payable functions
• view functions can be converted to non-payable functions
• 2. payable functions can be converted to non-payable functions

No other conversions between function types are possible.
The rule about payable and non-payable might be a little confusing, but in essence, if a function is payable, this means that it also accepts a payment of zero Ether, so it also is non-payable. On the other hand, a non-payable function will reject Ether sent to it, so non-payable functions cannot be converted to payable functions. To clarify, 3.rejecting ether is more restrictive than not rejecting ether. This means you can override a payable function with a non-payable but not the other way around.

Above statement 1,2,3 contradict each other.
any comment here? thanks.

2

Statement summary:

  1. if A is more restrictive than B, then B can override A
  2. if A is payable and B is non-payable, then B can override A
  3. non-payable (rejecting eth) is more restrictive than payable (accepting eth)

No contradiction here.

3
  1. if A is more restrictive than B, then B can override A
  2. if A is payable and B is non-payable, then B can override A (B is more restrictive than A，then A can override B) ----contradiction------
1 Like
4

Sorry, you’re right.
The paragraph that you’ve quoted from the documentation probably needs some rephrasing.

First of all, the order from most-restrictive to least-restrictive should be clarified:

+-------------+-----------------+-----------------+-----+
|             | storage reading | storage writing | eth |
+-------------+-----------------+-----------------------+
| pure        |        -        |        -        |  -  |
+-------------+-----------------+-----------------------+
| view        |        +        |        -        |  -  |
+-------------+-----------------+-----------------------+
| non-payable |        +        |        +        |  -  |
+-------------+-----------------+-----------------------+
| payable     |        +        |        +        |  +  |
+-------------+-----------------+-----------------------+

Second, the rules for overriding should be clarified.

5

thanks for your response.

6

Take a non-payable function as a payable function that requires to be 0. A non-payable function like this:msg.value

function myFunction() external {}
is (kind of) compiled to this

function myFunction() external payable {
assert(msg.value == 0);
}
Essentially, a non-payable function is more restrictive than the payable one. This is why you can use a payable function where a non-payable function is needed.

7

OK, I shall fix and rephrase my previous answer.

The core mistake in it was my interpretation of:

function type A is implicitly convertible to function type B

As:

function type B can override function type A

Instead of as:

function type A can override function type B

Once we fix this interpretation, there is no contradiction in the official documentation:

  1. if A is more restrictive than B, then A can override B
  2. if A is non-payable and B is payable, then A can override B
  3. non-payable (rejecting eth) is more restrictive than payable (accepting eth)

Here is the full diagram, from most-restrictive to least-restrictive:

+-------------+-----------------+-----------------+-----+
|             | storage reading | storage writing | eth |
+-------------+-----------------+-----------------------+
| pure        |        -        |        -        |  -  |
+-------------+-----------------+-----------------------+
| view        |        +        |        -        |  -  |
+-------------+-----------------+-----------------------+
| non-payable |        +        |        +        |  -  |
+-------------+-----------------+-----------------------+
| payable     |        +        |        +        |  +  |
+-------------+-----------------+-----------------------+