FLIP: interface inheritance in Cadence

[SupunS]

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

Reference implementation: onflow/cadence#2112

[dsainati1]

Nice! Thanks for writing this up. This is a really thorny design space so we should take care to iron out all the edge cases here. I had some specific questions below, but also some general ones:

1. How will this new feature interact with the proposed changes in Events emitted from interfaces  cadence#2069 or Allow composites to inherit events from interfaces cadence#2081 ? If events can be "inherited" from interfaces, how do they resolve in cases of multiple inheritance?

2. 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.

[SupunS]

How will this new feature interact with the proposed changes in onflow/cadence#2069 or onflow/cadence#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: d98d658

[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 (7127f6b).

Also added a new section on how the interfaces/conditions would be linearized (9005d7f). 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: onflow/cadence#2112

[turbolent]

Great proposal!

[turbolent]

Why is this forbidden?

[SupunS]

This is because of the type requirements. If there are types with identical names, the concrete type that implements these two interfaces might not be able to satisfy them both. So here it is taking the most restricted approach by rejecting such conflicts.

However, this can be relaxed after the type requirements are removed.

[joshuahannan]

I'm pretty happy with this! Just had one comment

[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 ➡️ onflow/cadence#2112