Arbitrary order of contracts in override specifier is confusing.

[apguerrera]

Version: solidity ^0.6.3
Platform: http://remix.ethereum.org/#optimize=false&evmVersion=null&version=soljson-v0.6.3+commit.8dda9521.js

Issue: override(Two, One) doesn't seam to have the intended behavior. Instead, it retains the contract import inheritance.

Example:

pragma solidity ^0.6.3;

contract One {
    uint256 public a;
    event Hah(string message, uint a, uint b);
    function foo() virtual public {
        a = 1;
        emit Hah("One::foo()", a, 0);
    }
}

contract Two {
    uint256 public b;
    event Hah(string message, uint a, uint b); 
    function foo() virtual public {
        b = 2;
        emit Hah("Two::foo()", 0, b);
    }
}

// Override contract One
contract OneAndTwo is One, Two {
    event Hah(string message, uint a, uint b);
    function foo() public override(One, Two) {
        super.foo();
        emit Hah("OneAndTwo::foo() after super.foo()", a, b);
    }
}
// Calls Two.foo()

// Swap override contracts
contract OneAndTwoReversed is One, Two {
    event Hah(string message, uint a, uint b);
    function foo() public override(Two, One) {        
        super.foo();
        emit Hah("OneAndTwoReversed::foo() after super.foo()", a, b); 
    }
}
// Still calls Two.foo()


// Swap import contracts
contract TwoAndOne is Two, One {
    event Hah(string message, uint a, uint b);
    function foo() public override(Two, One) {
        super.foo();
        emit Hah("TwoAndOne::foo() after super.foo()", a, b);
    }
}
// Now calls One.foo()

Thanks to BokkyPooBah for workshopping this and providing the code examples

[chriseth]

The override specifier has no semantic influence, it is a purely syntactic "clarifier". The order of contracts in the override specifier is arbitrary. Maybe we should require that the order is the same as the one deduced using linearization.

[apguerrera]

Shouldn't specifying the order in the override have an impact on super. is called in individual functions?

[chriseth]

@apguerrera the specific meaning of super does not only depend the contract, this keyword is used in. It depends on the full inheritance hierarchy, including contracts that the current contract is not even aware of.

[apguerrera]

Could override(One,Two) indicate your preferred ordering within the hierarchy?
Otherwise, if it is just arbitrary, why not simply leave it as override.

[chriseth]

It is not about specifying an order but about specifying which contracts you inherit from also define that function. Since the order of inheritance cannot be changed on function basis, you specify it when specifying the bases: contarct c is One, Two

[k06a]

What is the exact reason to add types into override keyword? I am afraid it is over-protection for developers also breaking existing Solidity best practices and programming principles. I was pretty sure that language evolution should go hand in hand with leading libraries/solutions build using this language. Did you eve heard that a new C++ standard broke STL approach?

[chriseth]

The main problem with forcing an order to me is that it is still unclear if that order would be "base to derived" or "derived to base".

[cameel]

@chriseth Why do we require specifying all the bases? I think the purpose of this feature is to make sure user knows which function gets overridden. Just specifying the base contract containing that function seems enough to achieve that goal. So it could work like this:

// Good.
contract OneAndTwo is One, Two { function foo() public override(Two) { super.foo(); } }
contract TwoAndOne is Two, One { function foo() public override(One) { super.foo(); } }

// Error. foo() does not override the function from the specified base.
contract OneAndTwo is One, Two { function foo() public override(One) { super.foo(); } }
contract TwoAndOne is Two, One { function foo() public override(Two) { super.foo(); } }

[cameel]

If we do want to keep the requirement to specify all the bases we could also make the order clear by requiring the user to mark the most derived one - since that's the only one whose placement could theoretically matter (unless the user expects to be able to reorder all the bases in the inheritance chain with override() but that would be ridiculous).

Some syntax ideas:

contract X is A, B, C, D { function foo() public override(A | D, B, C) { super.foo(); } }

contract X is A, B, C, D { function foo() public override(A -> (D, B, C)) { super.foo(); } }

contract X is A, B, C, D { function foo() public override(D, B, A*, C) { super.foo(); } }

contract X is A, B, C, D { function foo() public override(D, B, {A}, C) { super.foo(); } }

contract X is A, B, C, D { function foo() public override(D, B, A, C) through A { super.foo(); } }

contract X is A, B, C, D { function foo() public override(A) override(D, B, C) { super.foo(); } }