-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow call of access(contract)
interface function with a default implementation from an implementing contract
#3209
Comments
This causes a bug in the new token standards that I missed testing while we were iterating. Just fell through the cracks, so I take responsibility for missing it. As of now, this either would require an update to Cadence to allow or we'll have to update the token standard with a workaround, but I'm curious to hear if this behavior by the language is intentional or not |
@SupunS @turbolent Can you take a look at this? This is preventing people from being able to update their contracts with all the functionality in the token standards |
In my view, it is correct to say that any function with But then again, default functions defined with |
See Discord discussion: https://discord.com/channels/613813861610684416/1222979306880372777 |
This is different than the discussion about the |
Like, if I were to make this function |
I wouldn't consider the current behaviour a bug: A call of a I guess we could extend the access control mechanism and allow calls of the default function also from any code of a contract that defines a concrete type that implements the interface with the default function. Is this really needed though? It seems to complicate both the language semantics and implementation even further. As already pointed out in the Discord thread, the usage of |
access(contract)
function with a default implementation from an implementing contractaccess(contract)
interface function with a default implementation from an implementing contract
I was thinking we should even reject interface default functions with |
Yeah, I made a similar suggestion in the Discord thread, we might want to restrict this further instead of extending it, potentially even forbidding |
Well, I definitely wouldn't want to restrict it any more because that would break the For this issue specifically, the problem is with the NFT standard needing to be able to emit a standard event, but we want that standard event to only be able to be triggered by a contract for its own NFTs. I've just made the function |
interface can call the implementation but implementation cannot call the interface? I think both should be able to call each other ( without being public ) my mental model was when interface with default conditions is; there is no interface. Implementation and interface becomes one. Depending on how you access the resource/contract ( via interface or via type ), you see a limited view of the merged state. |
Current Behavior
A contract interface defines an
access(contract)
function and gives it a default implementation.A contract that implements the contract interface does not provide an implementation for the function, intending to use the default implementation, but when code in the implementing contract tries to call the function, there is an error:
Expected Behavior
The function should be able to be called by the implementation since it is
access(contract)
Steps To Reproduce
If an implementation for the function is added, the error goes away, but contracts may want to use the default implementation
because the default implementation in the contract may have access to some functionality that the implementing contract doesn't. This pattern is intended to be used in the V2
NonFungibleToken
standard with the function that projects can call to emit a standard event from the contract interface.Environment
The text was updated successfully, but these errors were encountered: