# \[Request For Comments\] - Contract Composition in Core Solidity **URL:** \ **Category:** Uncategorized\ **Created:** [July 8, 2026, 5:10pm UTC](https://forum.soliditylang.org/t/request-for-comments-contract-composition-in-core-solidity/3734 "2026-07-08T17:10:18Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![cameel](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/cameel/32/34_2.png) [@cameel](https://forum.soliditylang.org/u/cameel)\ **Post date:** [July 22, 2026, 12:33pm UTC](https://forum.soliditylang.org/t/request-for-comments-contract-composition-in-core-solidity/3734/5 "2026-07-22T12:33:34Z")
> Is there a reason for wanting to do away with classic solidity style inheritance? To put it shortly: a lot of complexity without enough flexibility. Inheritance is a very overloaded tool that is currently used to solve multiple orthogonal problems: - interfaces/polymorphism - namespacing/encapsulation - storage layout - code reuse/extensibility The issue is that conflating them makes things easy in simple cases but gets unmanageable when the code grows. This is especially evident in contract libraries. Having your storage layout tied to the linearization order of your contracts makes extending it harder, which is why historically various workarounds were used (storage gaps) and eventually standards like [ERC-7201](https://eips.ethereum.org/EIPS/eip-7201) emerged. The community is basically already choosing composition over inheritance for this use case. The language should follow. In terms of storage layout, the contract is pretty much a struct anyway. For namespacing we have modules. We’re also adding exports, which will provide encapsulation. Interfaces are the one place where inheritance makes some sense, which is why we are probably going to keep it in a way. In the new type system they are going to be modeled with type classes instead, but with a bit of syntax sugar this can be made to still look like inheritance. Extensibility is the aspect that leans the most heavily on inheritance. That’s where multiple inheritance, linearization and function overrides come in. The problem is that this gives you a lot of power but few safeguards. There’s tension between library authors trying to provide simple ways to extend the base implementation and the language trying to be explicit and not allow action at a distance. A good example is the long [discussion we had about the override specifiers](https://forum.soliditylang.org/t/thoughts-on-override-a-b-syntax/767) and when it’s fine to omit them (which then continued throughout several Github issues). The overall conclusion we had from that was that what’s needed a lot of the time is [more of a simple mechanism to add to the base implementation](https://github.com/argotorg/solidity/issues/7261#issuecomment-1023495547) than the power to completely alter the call chain the way virtual functions allow you to. Multiple inheritance in general is much maligned due to the diamond problem. To solve it Solidity mandates all inheritance to follow the virtual inheritance rules known from C++. This is workable, but does not make things simpler for the user. In general inheritance has a lot of moving parts and is the most complex feature currently in the language. It interacts with other mechanisms in ways that introduce a lot of corner cases. Initialization order, mutability (which can be different in overrides), shadowing, natspec and many other things have to be accounted for. On top of that, behavior in these corner cases is often not strictly specified so there are many bugs and unexpected quirks. It’s not like we could not have both inheritance and those other features that replace it, but we just don’t think it makes sense to put a huge effort into replicating it faithfully when the feature is this flawed. So what do we want instead? I’d say that the baseline is a mechanism similar to what you can get in Rust. You have traits (type classes), modules and structs as separate mechanisms and no inheritance. This is also the way Fe does it: [Contract composition](https://fe-lang.org/contracts/composition/). The main concern we still have is whether that’s good enough or if we do need more. For all its warts, inheritance often did make code reuse easy. A good example is how you can get a custom ERC20 token by inheriting from several base classes with very little extra code. In Fe’s composition model you do need a lot more boilerplate. The question is whether that will be an issue in practice. If we can address it by keeping some good aspects of the inheritance model, we will. This thread is an attempt to answer that question. --- _[View the full topic](https://forum.soliditylang.org/t/request-for-comments-contract-composition-in-core-solidity/3734)._