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

Make array and dictionary constants deep #4576

Closed
Trioct opened this issue May 22, 2022 · 2 comments · Fixed by godotengine/godot#71051
Closed

Make array and dictionary constants deep #4576

Trioct opened this issue May 22, 2022 · 2 comments · Fixed by godotengine/godot#71051
Labels
breaks compat Proposal will inevitably break compatibility topic:core topic:gdscript
Milestone

Comments

@Trioct
Copy link

Trioct commented May 22, 2022

Describe the project you are working on

Typical simple project to test Godot 4.

Describe the problem or limitation you are having in your project

const has an unintuitive and error-prone implementation.
A few open (there are more that are closed) issues related to the current definition of const:
#56306
#52422
#61274

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Constant arrays and dictionaries should be made permanently read-only. A few days ago we got #61087 and #61127, allowing a simple mechanism. With being read-only, they'll be copied on assignment(? whatever is implemented these prs. I think it's copy on assignment) Consts would be constant expressions instead of one-time assignable variables, as the compiler expects. #820 would be a better fit for what const arrays/dictionaries are now.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

My take on the problem is Trioct/godot@b044060, making const arrays/dictionaries permanently read-only. This allows #41983 to be reverted as well, fixing #52422.

Example:

const x := [3,2,1]
x.append(0) # Runtime error, x is read-only

var y := x
y.append(0) # Works, x is copied to y. x remains unchanged.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Doesn't really apply.

Is there a reason why this should be core and not an add-on in the asset library?

Don't think this applies either.

@Calinou Calinou added topic:gdscript breaks compat Proposal will inevitably break compatibility labels May 22, 2022
@Calinou Calinou added this to the 4.0 milestone May 22, 2022
@Mickeon
Copy link

Mickeon commented May 23, 2022

And to perhaps keep tbe current functionality (which I use greatly may I add), static could finally be used for variables as well?

@Calinou
Copy link
Member

Calinou commented May 23, 2022

And to perhaps keep tbe current functionality (which I use greatly may I add), static could finally be used for variables as well?

static var won't be added in the interest of thread safety. Static variables generally don't provide much benefits when you have autoloads anyway. See godotengine/godot#6840 and in particular godotengine/godot#6840 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaks compat Proposal will inevitably break compatibility topic:core topic:gdscript
Projects
Status: Implemented
Development

Successfully merging a pull request may close this issue.

3 participants