Please vote on a syntax for immutable variables (runtime constants) in GDScript - FINAL ROUND

[geekley]

GDScript currently uses a const keyword for compile-time constants. It may be getting support for immutable variables (runtime constants) too, but a consensus from the community is desired to decide on the syntax:

• Add support for immutable variables godot#99778
• Add support for immutable/one-time assignable variables #820

I have previously posted a preliminary informal poll with 8 suggested options, and an intermediate poll with 4 options.
As explained before, multiple rounds were used to account for secondary and negative preferences.
This is the last round, with only the 2 most voted options.

This poll is only about what the word itself should be. Whether it should be a prefix annotation to var or a standalone keyword (or even prefix keyword if allowed) is secondary in this poll.

Disclaimer: I'm not a member or contributor of the repo, so treat this as a non-official "community" poll, for reference only. It's up to the devs whether they'll actually consider it or not.

Suggested syntax options

Informational only, doesn't necessarily mean all features would be supported as shown.

let

Proposing it as a standalone keyword. Unlikely to be fit for an annotation.

static let scene: PackedScene = preload('res://Scene1.tscn')
@export let texture: Texture2D
@onready let sprite: Sprite2D = $Sprite as Sprite2D
func set_node(let node: Node) -> void:
  let parent = get_parent()

@readonly var | readonly

Showing syntax as an annotation (devs seem to be moving away from prefix keywords).

static @readonly var scene: PackedScene = preload('res://Scene1.tscn')
@export @readonly var texture: Texture2D
@onready @readonly var sprite: Sprite2D = $Sprite as Sprite2D
func set_node(@readonly node: Node) -> void:
  @readonly var parent = get_parent()

Could be discussed as standalone keyword as well (replacing var instead of prefixing it).

static readonly scene: PackedScene = preload('res://Scene1.tscn')
@export readonly texture: Texture2D
@onready readonly sprite: Sprite2D = $Sprite as Sprite2D
func set_node(readonly node: Node) -> void:
  readonly parent = get_parent()

Considerations

You can read the posts in #820 and #12635 for the community's considerations regarding familiarity from other languages, succinctness/verbosity, explicitness of its meaning, risk of clashing, risk of confusion, personal preferences, etc.

Again, I intend to close it in about a month (hopefully my reminder works this time; I'll set it to Saturday August 16th).
Again, I won't look at the votes until it's closed, and I won't vote (unless it's a tie at the closing date).

[Meorge]

Having this be an annotation would be consistent with how the GDScript leads have discussed their approach to keywords versus annotations, in my opinion, since it's modifying the existing behavior of a variable.

However, for simple readability reasons, I feel like it'd be better to use the let keyword instead.

@readonly var parent = get_parent()

is much more verbose than

let parent = get_parent()

to an extent that I feel the former's syntax could discourage its use, or at the very least make it harder to visually parse.

I will concede that let is not as immediately intuitive to read as @readonly. For most non-math-minded people, I don't think they would quickly understand that let prevents a variable from being reassigned. That's a big point against it for a language like GDScript that's meant to be beginner-friendly.

[dalexeev]

Note that GDScript's const is not the same as JavaScript's const too. I think you're overly concerned about JavaScript's importance and potential confusion. JavaScript is a client-side web language, not a gamedev language. These areas overlap, but not so much that you have to constantly worry about potential confusion over such a small thing. Even if someone confuses these keywords, they'll get a compile-time error very soon and realize it. It's not something hidden and incomprehensible, it's just a matter of habit.

There's simply no reason to use let in the same sense as JavaScript, since our var initially behaves like JavaScript's let (it works within a block, not a whole function). JavaScript's let is a consequence of their mistake in the past. They essentially deprecated var and introduced a new keyword instead, with a not very appropriate name. But this whole story has nothing to do with GDScript, we have no reason to limit ourselves because of twists and turns in the historical path of JavaScript.

Languages use different keywords in different ways all the time. Those who don't read the documentation and rely only on their assumptions and experience in other languages will inevitably encounter confusion. Sometimes much more subtle and painful than this one.

[geekley]

Well, I don't disagree. You make a lot of valid points and JS is indeed the weird one here.
It's just that I can't think of any other case where 2 programming languages have the same thing mean opposite things, so it seemed like a odd kind of uncertainty for me. But maybe it's not that odd, sorry if I seemed exaggerated, I don't mean to annoy or anything like that. 😅

[ssokolow]

I could also see Rust being a point of confusion, given that Rust's let mut is more the inverse of @readonly var.

[Meorge]

I mostly remember let in Swift doing what is being proposed here for GDScript:

let a = 5
var b = 3

a = 1 // error; can't reassign immutable variable
b = 2 // okay

[dalexeev]

I think there are many examples where two languages have similar sets of keywords that have different meanings. You just noticed the one you are familiar with, but you can't know how many cases outside your experience you might have missed.

For example, Pascal has the keywords procedure and function. Procedures differ from functions only in that they cannot return a value (in C and other languages, these are void functions). Nim has the keywords proc and func, but the difference between them is different: procedures in Nim are functions in other languages, and functions in Nim are closer to mathematical functions (they cannot have side effects).

By the way, if I understand the manual correctly, in Nim the keywords var, let, const play exactly the same roles that we have (and propose for let) in GDScript - variables, immutable variables, compile-time constants. This is an additional argument in favor of this option. (Disclaimer: I've never used Nim before, only read a little bit of its documentation, so I probably can't say I'm biased in favor of Nim.)

[sockeye-d]

no val 😔 (it should have won)

[geekley]

Did you mean val?
If so, I guess that means it is confusing after all 😆

[sockeye-d]

hey uhh that's what I typed originally... yes...

[Mickeon]

Not using readonly for this would go against GDScript's goal of being easy to parse and understand. I do understand that a "read-only variable" is an oxymoron, but with another keyword instead of var there would now be three mechanisms to declare something and assign it a value something in GDScript: var, let, and const . var and const are entirely different, but var and let not so much.

I was going to go on a big tangent, and I may in response to this, but in very simplistic terms, like a beginner may say:
"Why should I use let if it's much more limited than var?".

[dalexeev]

Note that readonly and immutability are not the same thing. Readonly means only that you cannot reassign the variable, but its value can change on its own (for example, if we allow a getter with a readonly member variable), while immutability means that the value of the variable (but not its contents in case of reference types) cannot change under any circumstances (we should not allow a getter). In my opinion, both readonly and immutable variables make sense to add to GDScript.

All this was already discussed in the main proposal. Modifiers like @readonly var are not ergonomic for local variables that can be used as immutable very often. If immutable variables appear in GDScript, I would personally use them by default, and var only if the variable should change its value. Also, we use a separate const keyword for compile-time constants, rather than something like @compiletime @immutable var.