I don’t understand what is the “compile time constants” ?
I mean what is the difference between :
val name:String = “Bebo”
const val name2:String = “Bebo”
name + name is compiled as "Bebo" .concat( "Bebo" ) (*)
name2 + name2 is compiled as BeboBebo
name is a non modifiable reference to a String
name2 is a constant that can be evaluated at compile time
(*) it is a bit more complex
2 Likes
Sry I really didn’t get xD I’m still learning
I mean what is the difference between
Compile time initialization
And
Run time initialization
The difference is super minor so I wouldn’t worry about it too much. The difference is as fvasco tried to explain that constants are known at compile time. That means that if you have operations like string concatenation or addition, etc for numbers the compiler can calculate the result of those operations at compile time and just add the result in the generated bytecode.
If you don’t use constants the compiler won’t calculate the result of those operations ahead of time and just generate the bytecode to execute the operation when you need the result.
That said those kind of optimizations don’t have any (noticeable) effect on performance, so const isn’t used for this. In my experience it is mostly used to hard code database keys, file extensions, etc.
It doesn’t have a real effect on your program. It’s just a way of saying: “This val will never change (not even in an update to the program)”
If you are still confused I would suggest to not use const. You can always add const later, but if you are writing libraries there might be problems with removing the keyword.
1 Like
Thx bro but I still a little confused
Correct me if I wrong
If I write this code :
var x:Int = 10
var z:Int = x
If I compile my program the compiler will not add the value 10 to Varibale z but it will add it
After I execute my program only.
And if I write this code :
const val x:Int = 10
var z:Int = 10
and if I compile this program the compiler will add the value 10 to the varibale z , like if I said var z:Int = 10
Sry for my bad english
Yes you are right.
1 Like
Thx bro 
Sorry bro one more question , does that mean that “compile time constants” doesn’t use the memory ? And the the value for constants will be stored with the bytecode himself
No kotlin will still generate a normal property so you can access the constant from java. So const might lead to slightly bigger programs, but in practice you won’t notice. Compilers are quite good at optimizing stuff like that so you won’t notice. Also Strings are normally only stored once in each program. For example if you have multiple places with the same string constant (val foo = "very long or short text") the compiler will add this only once to the bytecode and then just reference it every time it is needed.
1 Like
Thx bro , you helped me a lot
I thinks that this is far too strict definition. Why it shouldn’t change in the future program update? I think that it can change by every compilation.
Does the Kotlin documentation have any guidelines regarding when to use “val” and when to use “const val”? If not, it should.
Not that I’m aware of.
Yes, you could change it with every compilation, but that would be a bad idea if you are writing a library (I don’t think it matters for applications).
If you use const in a library and change it from version to version it can lead to a situation where you have 2 sub libraries that are compiled against different versions of you library. If both of those are used in the same application again you have different values for 1 variable. That might be what you want, but I’d be careful about that.