Inheritance: allow stricter mutability

[fulldecent]

Code example 1:

pragma solidity ^0.4.19;

interface NamedThing {
    function name() public view returns (string _name);
}

contract Bob is NamedThing {
    string public constant name = "Bob";
}

Code example 2:

pragma solidity ^0.4.19;

interface NamedThing {
    function name() public view returns (string _name);
}

contract Bob is NamedThing {
    function name() public pure returns (string) {
        return "Bob";
    }
}

Discussion

These two cases illustrate where an implementing contract meets the requirements of an interface. However, both cases are rejected by the compiler with the error:

Overriding function changes state mutability from "view" to XXX

Mutability is expressed in these forms:

1. Payable
2. Nonpayable
3. View
4. Pure

These are strictly ordered. All pures are views, all views are nonpayables. All nonpayables are payables.

Recommendation

The compiler should allow class inheritance / interface implementation if the downstream function has a stronger mutability guarantee.

[fulldecent]

pragma solidity ^0.4.19;

contract Bob {
    function name() public pure returns (string) {
        return "Bob";
    }
    
    modifier makePureToView {
        require(address(this) != address(0));
        _;
    }
    
    modifier makeViewNonpayable {
        address[] storage a;
        _;
    }
    
    modifier makeNonpayablePayable {
        require(msg.value == 0);
        _;
    }
}

[axic]

I think this is a good idea to allow reducing the state mutability levels during inheritance, but we should really examine all the effects before implementing the change.

Question is: should the external interface be based on the final implementation or the interface?

[fulldecent]

For the "ABI" (which is not actually a binary interface), the stricter guarantees should be presented.

And for the actual external interface, i.e. EVM, there is no difference since this is not part of the function signature.

[fulldecent]

@axic Could you please help identify stakeholders for this issue and who would need to sign off? And we can query their issues/questions/concerns.

I am hoping to have this issue "accepted". This means we can be confident it will be implemented at some point (do we have a GitHub issue label for that?)

I care about this because standards work depends on this. Right now that standard (draft) is written in a way that assumes #3412 will be implemented at some point. It would be very helpful if I could justify such an assertion.

References:

• EIP-721 Non-Fungible Token Standard EIPs#841

[fulldecent]

Also can we please evaluate if this test case should pass or fail:

Test case 1

pragma solidity ^0.4.20;

interface Math {
    function calculateMostCommonNumberInSolidityDocumentation() external payable returns (int);
}

contract MathImplementation is Math {
    function calculateMostCommonNumberInSolidityDocumentation() external returns (int) {
        return 69;
    }
}

Test case 2

pragma solidity ^0.4.20;

interface Math {
    function calculateMostCommonNumberInSolidityDocumentation() external returns (int);
}

contract MathImplementation is Math {
    function calculateMostCommonNumberInSolidityDocumentation() external payable returns (int) {
        return 69;
    }
}

Discussion

In the discussion of the deed/NFT/DAR standard ethereum/EIPs#841 we have specified which functions are payable and which are not. The 0x team argues that it is not in scope for a standard (an interface) to specify whether functions are payable.

I think this discussion has wider applicability in the Solidity ecosystem so I have brought it here.

[fulldecent]

@axic Sorry, posted to the wrong place. Moving here.

Referencing your comment #3458 (comment)

I think the current specific rule in the code is that a contract implementing an interface may not modify the state mutability level of a function.

State mutability is defined as (the only summary - there is also another suggestion to move selfdestruct into another state mutability level):

stateMutability: a string with one of the following values:

• pure (specified to not read blockchain state),
• view (specified to not modify the blockchain state),
• nonpayable (cannot accept value transfers) and
• payable (can accept value transfers).

Above the state mutability level is increasing from pure (nothing) to payable (everything).

What are the reasons proposed for disregarding the payable keyword for interfaces?

[chriseth]

Agreement from call: We should have this.

Unless anyone can come up with an example why this might be a bad example, we should check it on the inheritance graph instead of the linearized hierarchy.

[chriseth]

Discussion: maybe take payable / nonpayable out because it is more complicated.

[ekpyron]

I'm fine with taking payable/nonpayable out in the first step. Once we want to go for it, I'd say this:

Overriding something payable with something non-payable is fine (after all you could also implement a payable function with require(msg.value == 0); in the beginning) - but overriding something non-payable with something payable is not fine (since calling in the base contract should always be able to assume that there is a callvalue check).

Actually if we don't allow overriding payable with non-payable, then we should also not allow overriding payable with view or pure, because it has the same problem. But I think the following is fine:

The as far as I'm concerned, the order is payable < non-payable < view < pure, increasing is fine, decreasing isn't.

[axic]

Overriding something payable with something non-payable is fine (after all you could also implement a payable function with require(msg.value == 0); in the beginning)

I think that is correct, but at the same time it just opens the door for unwanted mistakes. We should also decide how much we try to ensure people avoid mistakes vs. "somehow forcing them" to be more depending on tests and not the compiler.

[chriseth]

Implemented in #9344

[fulldecent]

Is there any appetite here to allow a payable to be overridden by a stricter type (non-payable, view, pure), the way that other override-with-stricter is possible?