Final/non-inheritable contracts

[androlo]

It is likely that people will use inline asm to create shortcuts around the standard storage and memory allocation procedures (I know i will). This could make the contract super efficient, but impossible (or at least dangerous) to extend. Maybe at some point there should be a flag that can be used to make contracts un-inheritable, like for example final is used for methods and classes in Java.

[androlo]

Guess it ties in with this: https://www.pivotaltracker.com/projects/1189488/stories/111152000, since it also has to do with whether or not something can be modified. Variables, functions, and contracts, code and storage. Messy hehe :D

[androlo]

(i realize these are different things, but basically just looking at different ways things can be allowed to be extended/modified or not; functions, contracts, and variables)

[androlo]

Maybe sealed.

[axic]

@androlo does the fact that libraries cannot inherit or be inherited helps this?

[androlo]

No you can't put this type of code in libraries because they can just be used without extending at all (basically there's no language features that can stop someone from using a function that may conflict with normal code).

The example is I make a contract with functions for writing directly to storage through assembly. If someone just extends the contract, or I put it in a library they can just link to, then they may then add new variables, and the auto allocation could conflict with the assembly routines that uses hard coded storage addresses, leading to weird errors.

Maybe it's a documentation thing, or maybe this type of optimization is not really a good idea. Having final or sealed or something is just how I'd generally deal with stuff like this, but perhaps it's not good for Solidity. If you're cleaning up issues just close this one.

[chriseth]

This is something to consider, please let's keep this open.

[axic]

Do we agree to call this sealed (or final)?

Would it reject the class to be subclassed or reject overriding defined functions?

[ethers]

If it's called final, would be good to see how consistent the behavior would be with the semantics of Java's final (there's more to it, but could just start at the class level).

As a starting idea, in Remix could this be an error:

contract Token {}
contract final MyToken is Token {}
contract CopyToken is MyToken {}  // sees that MyToken is final and so error and refuse to compile

[federicobond]

Not sure if this has been discussed before, but final for variables would be interesting too, with semantics similar to Java: final variables can only be defined once in the constructor and cannot be modified after that.

If we want to support auxiliary functions invoked from the constructor we would have to traverse the call graph though.

[VoR0220]

final seems to me to be redundant in the sense that pure or immutable (whichever it ends up being called) can be applied to various parts of the contract code.

[axic]

I think applying pure/immutable (they are not used in the same context though in other features) to a "contract" would convey the meaning that it cannot change state, wheres final has a different meaning.

[ethers]

Some notion of final is helpful in the context that there times (even the majority?) when the visibilities that people should be specifying on their functions are external rather than public. But public is tied to inheritance, and that may be the concern why external is used less?

[axic]

I don't think public is tied to inheritance, the only difference is it makes the function available to be called internally too (ie. with a jump and not via a call).

[ethers]

the only difference is it makes the function available to be called internally too

If that's the case, I think most uses of public would probably find that they should be external.

I think public means 3 things in Solidity: callable externally, internally, and internally by derived contracts. A contract writer writing foo() has no idea how derived contracts will be, and may want to allow derived contracts the optimization of being able to call foo() internally: so in this case making foo() public is excusable. Without the 3rd case, if contract writer didn't internally call foo() themselves, then little excuse for them and they should make foo() external.

[axic]

We've discussed this issue on the daily meeting and it seems that potentially #5424 will solve this: if none of the functions (including the constructor) is virtual, then no inheriting contract can change them, effectively making the contract "final".

@androlo @ethers what do you think?

[androlo]

i guess it doesn't address this particular issue since people can still add new functions, but this seems like a non issue in the first place. never heard of someone getting bugs because of this.

[chriseth]

Closing after #5424