I think implicit declarations on type restrictions to AnyStruct or AnyResource is bad idea in the long run.
Most common problem I see in the deployed contracts is developers skipping base type, just declaring only restriction. Which can cause security issues.
Also 99% of use cases you need to declare type with restriction.
I think changing that to explicit declaration with backward compatibility would be beneficial to ecosystem.
A bit more context on the problem here; there are two reasons to use interface specifications on types:
Classic polymorphism absolutely has its place in Cadence; when I publish a Fungible Token Receiver, I don’t want you to assume that the receiver is a Vault. It can be any kind of object that programatically routes the incoming funds however I want.
The question then is: Is it enough of a “gotcha” for someone who should be using the type restriction facility to accidentally use the polymorphism functionality. For example, using &{Balance} (which is easy to fool) vs. using &Vault{Balance} which provides some guarantees.
I find myself agreeing with Bluesign here: The cost of getting this wrong could be significant, and Cadence mostly emphasizes clarity over brevity (intentionally, I might add!). Having to explicitly say “I’m expecting any object here, so long as it implements this interface” is a good flag, and makes it clear that you meant to use the polymorphism facility here, and also makes it easier for reviewers/auditors to catch the problem. Indeed, you could imagine that a good Cadence linter wouldn’t let you use the short form here, and “good practice” would rise around not using it.
I’m all for making that a language requirement.
Agreed. I can think of many times in my and other people’s code where there has been confusion about what type we are restricting something to and this would make things much more clear. We should definitely include this! 