for example:
Var text = "hello world"
and then doing something like
text.toConst() where it makes it so that text is now a const

    Viffx consts are compile time, their value must be known before the game starts.

      You can’t make a variable const after the fact, but you can get close with methods: have a set() method to set the value, a get() to read the value, and a make_const() to block set() from working. Or you can use the similar “builder” pattern if that works better for you.

      • xyz replied to this.

        axolotl you can get close with methods: have a set() method to set the value, a get() to read the value, and a make_const() to block set() from working

        The question again is - why? Why would you want to do this. Intermittently "preventing" variable assignment by "making it const" sounds confusing and against the spirit of language. We really need to hear what the OP is hoping to accomplish with this because there may be a better way to approach it that doesn't include paradoxical concepts like turning vars into consts.

            xyz its not paradoxical. actually it could be very handy. for me i dont understand the difference between const and var. they both contain some data, why would it matter if its const or var? I mean i get the concept that const are precompiled, but you can also set a var the same value and use it ?

            The use case converting to const would be lets say you have a timed event where you want to set the variable to const so that it cant be changed and so if some other method triggers something while its in that state then it wont be changed, after event is passed then you can reassign the const to var again and changed values as needed.

            Ofc. you can rewrite whole routines to check if its that event where you are not allowd to change value, or let the computer do so by changing one parameter/type.

            idk.. im no bread engineer so my mileage could vary on this topic

                kuligs2 its not paradoxical

                It is. Because, as @Jesusemora already said above, consts are compile time declarations. If you declare something a const, you make a hard promise to the compiler that you have no intention whatsoever to change its value during runtime. The compiler then uses this fact for performance optimization as well as type safety. That's the whole point of const by definition. You can't turn const-ness on and off during runtime. This is true in all languages that support const declarations. If there is even slightest need for a variable to change, then it can't be declared const, even if you want to keep it "locked" for most of the time.

                If you have thoughts of turning consts into vars at runtime - you don't fully understand what a const is, and you're probably misusing it.

                Conditionally preventing a change of a property value at runtime is conceptually a different thing altogether, and it falls under the umbrella of OO encapsulation. The language has other features for that.

                  kuligs2 it cant be changed

                  Aa @xyz said, this is done through encapsulation. You are not supposed to access loose variables of a class from another class, it's ok in some gdscript code that is very small, but ideally you want to request variable values and request changes through functions. Like:

                  get_health()
set_health(5)
Damage(5)

                  This gives you the ability to extend and refactor code, because you can change the variables of a class or the way these are accessed (Damage() can set it to 0 if it goes negative) without having to change anything in the script that interacts with the class.
                  The script that interacts with the class knows that get_health will return an int, and doesn't need to worry about anything else. This also makes coding easier and allows you to work with a team where different people work in different parts of the program at the same time.

                  • xyz replied to this.

                      Jesusemora Note that in 4.x you don't need to explicitly call setter/getter methods. GDScript's set/get mechanism will always call property's declared setter/getter when the value of a property is assigned or retrieved (e.g. via assignment operator etc.)

                        There's no point in adding suggestions until the OP explains why he wants to "make a var a const".

                          DaveTheCoder There's no point in adding suggestions until the OP explains why he wants to "make a var a const".

                          That was my initial response. This is surely some kind of xy problem question.

                          But to put it bluntly, the answer to the literal question "Is there a way to make a var a const?" is: No, there isn't.