Remove Public Fields from Resources

[dsainati1]

Issue To Be Solved

Public fields on resources present a usability problem for developers, by allowing them to unintentionally expose functionality, data or information that they did not intend to expose. In Cadence generally, and specifically for code constructs like resources that deal directly with real-world value, it is important to be explicit about what functionality is available. As such, using public fields on resources is already largely considered to be a poor practice, and should be avoided where possible.

If we would like to make it easier to write safe code in Cadence, and decentralize the process of deploying contracts on Flow, it might be valuable to make the best practice of not using public fields on contracts explicit in the language by simply banning them entirely.

Suggested Solution

We could remove the ability for developers to declare a public field on a resource, instead requiring them to use private (or contract) scoped fields on resources, and providing getters/setters or other accessors if they wish to expose more general functionality to users. We should propose this change to the community via a FLIP to collect their feedback on this idea.

[bluesign]

As such, using public fields on resources is already largely considered to be a poor practice, and should be avoided where possible.

Is this really true? I feel totally opposite

I think removing fields from resources is a strange proposal. I feel like this will turn resources into black boxes. We will lose some interface restrictions powers.

Maybe getter/setters can help, but technically they are same thing as public functions. ( getBalance function vs balance property )

Not sure how I feel about id only resources (which is already a trend)

I am more in favor onchain access of all data if possible (hiding something onchain is trouble delayed)

I feel already we have bloated code, this will add a lot code duplication. You will make structs for function returns, construct them on get calls etc.

[dsainati1]

Thanks for the feedback! This is exactly the kind of input I was hoping to get by making this issue! I would love to hear a little more detail on your thoughts here.

I feel like this will turn resources into black boxes.

Can you elaborate on why you feel this is a bad thing?

Maybe getter/setters can help, but technically they are same thing as public functions. ( getBalance function vs balance property )

I think the difference here is that while you may wish for a larger interface to be available within a resource, you may wish only to expose a subset of those functions externally. A getter function allows the user to expose a more limited selection of functionality for each field (consider a field that is a Vault, for example, but whose getter function only returns a Receiver type). While users may not wish to restrict every field this way, one might argue that making such a choice explicit would improve safety and readability.

[dsainati1]

I have submitted a FLIP PR proposing this change more officially; note that this doesn't necessarily mean the change is going to happen, the FLIP is simply meant to flesh out the idea and propose it more formally.

[turbolent]

The FLIP was rejected.