Hi,
Thanks very much for this considered and thorough treatment.
Consistency
Most likley controversial feedback first: I see interfaces and abstract contracts as serving two different use cases. The safety offered by override seems to come at the cost of making simple uses of interfaces less apealing. And trying to treat them as the same as abstract methods is contributing to that effect.
Use case 1.
I don’t understand how both “Without any keyword the compiler cannot detect mistakes” and “In many cases this check is redundant because if there is a mismatch, the compiler will notice that not all functions from the interface have been implemented” can both be true. What is going on there ?
I am in favour of option 2 variant A. On the grounds that:
a) It feels like a big compromise for a rare case. A case I think likely only a real problem in complicated inheritance graphs. The silent override of ‘validate’ ilustated by @ekpyron I think only applies if abstract contracts are in the graph ? @ekpyron suggested here that scenarios where override saved the day were possible without mixing abstract and interface. I don’t have the solidity depth to challenge that.
b) It diminishes the significance (to the programmer) of the override keyword - pointed out by @nventuro here. I strongly agree with this point.
c) Isn’t a linter a better place to catch this sort of thing ?
d) In our consortia private deployment scenario this is a complete non issue. I only make this point to acknowlege that our uses are not remotely comparible to contracts on public eth.
I would prefer a class level opt in. When I write B in ekpyron’s example and I’m choosing to inherit from sophisticated 3rd part contracts with serious audit behind them I declare my contract to require these controls. I appreciate that bifuricates the compiler paths and testing and validation and that is not free, but it seems like what I would want. Even so, the current implementation of override applied in this way would still suffer from the signal/noise problem.
Use case 2 yes, finding a solution that doesn’t impact interfaces in this way would be great!
Use case 3. This just seems to require the programmer to both inspect the details of all the contracts they inherit from (fine I do that anyway), and then convince the compiler they have done so. I don’t want to do the second bit. Typing the names of the functions I am overriding doesn’t guarantee (or even softly imply) I have understood what I have looked at. Assertion: Everybody presses ‘y’ without thinking all the time.
Use case 4. yes, the thing I find most valuable about interfaces is not helped by override
Again, thanks very much for continuing to consider this issue with care.
Robin