Skip to content
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

feat: shadowing gno1 #1779

Open
petar-dambovaliev opened this issue Mar 15, 2024 · 2 comments
Open

feat: shadowing gno1 #1779

petar-dambovaliev opened this issue Mar 15, 2024 · 2 comments
Assignees
Labels
breaking change Functionality that contains breaking changes gno-proposal Gnolang change proposals 📦 🤖 gnovm Issues or PRs gnovm related security Security-sensitive issue

Comments

@petar-dambovaliev
Copy link
Contributor

petar-dambovaliev commented Mar 15, 2024

After a discussion with @jaekwon, we reached a conclusion that for gno, we want to allow shadowing of identifiers which are defined in a local scope. This means that a user cannot shadow any global identifiers and therefore uverse identifiers.
The main reason for this is one of readibility and security, as people tend to think they know what something is and not verify.
Allowing local scope shadowing will be sufficient for minimizing the ergonomics impact.

Relevant issues
#1758
#1091

The side-effects of this decision means that whenever we add a new uverse identifier, it would be a breaking change.
As far as gno2, which is not yet clearly defined, we plan to have a rule as capitalized identifiers to be excluded from shadowing.

@petar-dambovaliev petar-dambovaliev self-assigned this Mar 15, 2024
@petar-dambovaliev petar-dambovaliev added breaking change Functionality that contains breaking changes 📦 🤖 gnovm Issues or PRs gnovm related gno-proposal Gnolang change proposals labels Mar 15, 2024
@jaekwon
Copy link
Contributor

jaekwon commented Mar 15, 2024

Thank you Petar1!
There is still the issue of whether to allow or disallow package level global shadowing.
uverse global > package level global > func decl locals >= other block locals.
We might deviate from Go and not support new globals after launch.
Maybe they can still be supported with directives.

@kristovatlas kristovatlas added the security Security-sensitive issue label Mar 20, 2024
petar-dambovaliev added a commit that referenced this issue Mar 23, 2024
implements [this](#1779)

Most of the changes are fixing stdlib code where we get errors because
of the new shadowing rules.
@petar-dambovaliev
Copy link
Contributor Author

The first iteration was done. This issue can stay open for the rules mentioned above that are for gno2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Functionality that contains breaking changes gno-proposal Gnolang change proposals 📦 🤖 gnovm Issues or PRs gnovm related security Security-sensitive issue
Projects
None yet
Development

No branches or pull requests

3 participants