# Solidity Function Types conversion

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.

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)

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

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.

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.

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`

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     |        +        |        +        |  +  |
+-------------+-----------------+-----------------------+
``````