Constructors

[ItsNickBarry]

Constructors are not used because they are generally not compatible with upgradeable contracts. However, some contracts require initialization, so users must write their own constructors.

We could include overridable _constructor functions in each contract. Possibly unimplemented, to force the user to override and make some decisions specific to the contract (and encourage setting immutable variables to replace certain storage accessors).

// _Ownable.sol
constructor () {
    _Ownable();
}

function _Ownable () internal virtual;

Or we could offer a library of composable initializers for users to import and call depending on which contracts they're using.

// Solidstate library
library Constructor {
    function Ownable () {
        _setOwner(msg.sender);
    }
}

// user's contract
constructor () {
    Constructor.Ownable();
}

The former approach will cause problems with hardhat-exposed. The latter is error-prone, both on the user's end and in cases of API changes.

[zimmah]

I like the latter option. What are the main risks regarding it being error-prone? Is there something we could do to reduce those risks for the user?

[ItsNickBarry]

It's easy to forget to call a library constructor function after inheriting from a contract that needs one. The solution would be the former option, which would prevent contracts that don't override _constructors from compiling. Maybe we could do both - give the user a helper function in a library but force them to call it manually from _constructor. But I don't think that's an improvement over what we have now. So this issue probably won't be addressed.