FLIP: interface inheritance in Cadence

[SupunS]

Discussion: https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750

Reference implementation: https://github.com/onflow/cadence/pull/2112

[SupunS]

How will this new feature interact with the proposed changes in https://github.com/onflow/cadence/issues/2069 or https://github.com/onflow/cadence/issues/2081 ? If events can be "inherited" from interfaces, how do they resolve in cases of multiple inheritance?

Thanks for bringing this up! I was thinking the type definitions would also behaves similarly to the default functions. Added a section for this: https://github.com/onflow/flips/pull/40/commits/d98d658f60cfa5b20436426e604e49e331eb7c7e

[SupunS]

I think this change would also benefit from a redundancy check in any places where a list of interfaces might appear. In a conformance list, for example, it would be redundant to say MyVault: Receiver, Vault, so we should have a static error warning that the Receiver annotation is unnecessary in the presence of the Vault annotation. The same would go for restricted types' restriction lists.

Yes definitely, we could add a redundancy check for conformances. Having redundant conformances can sometimes cause static errors by the current rules (i.e: when there are overridden default functions, etc.). Others can be checked at a linter phase.

[turbolent]

It looks like Swift's solution is to reject diamond conflicts, instead e.g. picking a certain default implementation: https://www.vadimbulavin.com/multiple-inheritance-swift/

[SupunS]

We had a breakout session regarding the diamond problem today, and rejecting the default function conflicts (as proposed in this FLIP) was favored by the majority.

A detailed summary of the solutions discussed in the meeting is as below.

• Reject ambiguous cases (proposed in the FLIP)
  • Concern:
    • Someone higher up the chain can break downstream code by introducing a default implementation.
  • Conclusion: Accepted solution ✅
• Cadence to pick one, maybe the one closest to the current implementation.
  • Concerns:
    • This may result in unintended/surprising behaviors.
    • Already disregarded this option for default functions ambiguity resolution in concrete type implementations. (They also behave very similarly to what is proposed in the above FLIP)
  • Conclusion: Too "magical" 👎

• Users to “lock in” to an implementation, optionally.

  • e.g:

    pub resource MyVault: Vault {
        pub inherited<Receiver> fun log(_ message: String)
    }

  • Concern:

    • This is optional. Doesn’t guarantee developers will use it. Their code could break if they don’t, same as the original FLIP proposal.
    • Cannot mandate this ‘locking-in’. Because it would contradict the original intention of default functions - which is to update interfaces (add methods) without breaking the downstream code.

  • Conclusion: Doesn't really solve the problem 👎

[turbolent]

@SupunS Nice!

It looks like the decision needs to be reflected in this section: https://github.com/onflow/flips/pull/40/files#diff-0e651e7f8b8bd0a53ffe1e6333ac854ee0a0c7c6932d1bbcd3b51883f18161e8R190-R194

[SupunS]

Updated the FLIP with the latest discussion outcomes (7127f6b198dd85a097de4867d3806faed745da74).

Also added a new section on how the interfaces/conditions would be linearized (9005d7f7bd699fdcb53645252cbeb88f3d9d3e2e). TL;DR is, conditions are linearized in a depth-first pre-order manner, ignoring any duplicates (duplicates are cases where there are two or more paths to the same interface/condition).

[SupunS]

Reference implementation: https://github.com/onflow/cadence/pull/2112

[SupunS]

Thanks everyone for the suggestions and feedback for this proposal so far!

This FLIP has been open for a while, and it seems we are all happy with the current proposal, and seems there are no any remaining concerns. Thus, I'm going to consider this FLIP as accepted 🎉 🎉 🎉

You can follow how the implementation is progressing here ➡️ https://github.com/onflow/cadence/pull/2112