Please vote on a syntax for immutable variables (runtime constants) in GDScript - intermediate poll

[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. It was only intended as a starting point -- since it allows duplicate voting, and some options would split voting among similar syntax, I felt like it should be done more properly here.

Now that it gathered a good amount of votes, this is a more "formal" poll with a reduced set of options (half) from before as a second round. The 2 most voted choices then move on to a last round, probably about a month from now. So, even if you have multiple options you like or dislike, vote for your best preference without worrying about it, as you may vote on your secondary preference later.

This poll is about what the word itself should be. Whether it should be a prefix keyword to var, a standalone keyword or an annotation could be as recommended here, but that 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.

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 a prefix keyword or 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 var | readonly

Showing syntax as a prefix keyword. Could be discussed as annotation, or even standalone keyword.

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()

val

Proposing it as a standalone contextual keyword. Unlikely to be fit for a prefix keyword or annotation.
This option is on the assumption a contextual keyword can be used so val doesn't become a reserved word.

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

var val: int = 0 # using it as identifier would be still be allowed

final var | final | @final var

Showing syntax as a prefix keyword. May be preferable as a standalone keyword without var, or even as annotation.

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

Considerations

You can read the posts in #820 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.

[sockeye-d]

You can put polls in discussions??

Also I would prefer val since it's what Kotlin uses and I like Kotlin, and I think it effectively communicates the difference between a mutable variable and a read-only value.

[sockeye-d]

You'd think it'd get annoying, but I've been programming Kotlin for a few months and it's not that bad

[ssokolow]

The same could be said about any property of any programming language. There are people who enjoy programming in C++ and people who feel it's like walking around in a field full of rakes and constantly getting whapped in the face.

Your anecdote does not apply generally.

[sockeye-d]

While I agree it would seem like it would be hard to tell the difference, the other part of it is that to encourage immutability (which is generally better to create safer programs) it should be as easy to create an immutable value as possible. That's why I don't think something like readonly var makes sense, since it makes the code look quite ugly and quite a bit longer as well.

[ssokolow]

If length is a problem, something like rovar or var:ro could be proposed. (The latter syntax being inspired by Flatpak's syntax for applying permissions to granted paths in sandboxing manifests. (eg. ~/src/myproj:ro)

There are probably others too... I just don't consider it reasonable to use words that have such variable meaning across various languages people will be coming from, nor do I consider it reasonable to use a word that's so visually similar to its alternative in a context where mixing them up is unlikely to result in an error message.

[geekley]

I won't vote or look at the votes until it's closed, and I wanted to avoid posting here...

But I feel like final (without prefix) should have the least rejection... even if it might not be most people's number 1 choice. Saving 2 chars with let or val seems like it's not worth the risk of confusing a significant number of people.

• readonly screams immutability, so it would be great if it wasn't for its verbosity, specially as a prefix; ideally immutable locals/internals should be preferred by default, and made mutable only as needed; but if it's too verbose to type, people may just ignore it and use var without caring
• let clashes with JS meaning mutable, and people coding for Godot 4 web projects will have to deal with JS and GDScript in the same project; having it mean not just different, but opposite things WILL confuse people, specially those new to programming
• val is disliked by people who think it's confusing or would clash with a val identifier; might be specially bad for Asians, since in Japanese, Korean and some Chinese L/R has a similar pronunciation
• final as non-prefix keyword seems like the balanced option - not too verbose (as succinct as const), explicit enough about its meaning, there's a precedence in Java and it's unlikely to break much existing code even if it becomes a reserved word; plus if GDScript ever implements "sealed" classes or methods, this keyword could be reused like in Java

[TX256]

In my humble opinion, let just does not feel intuitive or descriptive enough, I would leave it for the mathematicians... It also kind of has too big a contrast to var.

I agree with sockeye-d, val is just fine, I've used Kotlin quite a lot and I give another vote for it for not being "too easily confused to var". It's a quite natural counterpart for var.

Failing that, final would be fine.

EDIT:
Another point of view: I understand the benefits of immutable variables, but having simply only var would keep things simple... (and
perhaps be in the "spirit of GDScript")

[geekley]

Important Update

There's a discussion that may lead to a potential decision from devs to get rid of prefix keywords entirely, moving all of them to annotations (it's possible even @static might become an annotation). I wanted to edit the examples above to reflect that as a likely scenario, but since apparently I cannot edit a poll description without resetting votes, I'll just comment here.

So, when voting, keep in mind that the prefix keyword variation might not be an option.
These examples might be more likely:

let

func set_node(let node: Node) -> void:
  let parent = get_parent()

@readonly var | readonly

func set_node(@readonly node: Node) -> void:
  @readonly var parent = get_parent()
# or
func set_node(readonly node: Node) -> void:
  readonly parent = get_parent()

val

func set_node(val node: Node) -> void:
  val parent = get_parent()

final | @final var

func set_node(final node: Node) -> void:
  final parent = get_parent()
# or
func set_node(@final node: Node) -> void:
  @final var parent = get_parent()

Assuming there would be a syntax to make parameters immutable. So note that, if going with a standalone keyword variant, I don't know if devs would exceptionally allow it as prefix on parameters, or use some other syntax for immutable parameters (e.g. make it an annotation too), or just not implement immutable parameters (like in JS) as shallow immutability on pass-by-copy parameters is just an implementation nicety, irrelevant wrt. the exposed API (doesn't affect the function signature).

[geekley]

Poll results

(I intended to close it on 19th, but Google Calendar didn't notify my reminder for some reason, so I'm closing it now)

Total votes: 40

• let: 45%
• readonly: 25%
• final: 17%
• val: 12%

let and readonly advance to the final round, please vote again before Saturday, August 16th:

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