'let'

[GiorgosAlexakis]

'let' could definitely be one of the reasons to avoid the language for me:D

[igotfr]

'let' could definitely be one of the reasons to avoid the language for me:D

the equivalents are:

• const in Rust, constexpr in C++
• let in Rust, const in C++

I prefer type const and let than constexpr and const

[freedxmgxd]

'let' could definitely be one of the reasons to avoid the language for me:D

why?

[Twins-Divyanshu-Sharma]

yeah I mean why use 'let' for constants. Why not 'const' or its synonyms ?
If 'const' is already there, why not use 'final' instead.
How does 'let' tells you that its a constant value ?

[GiorgosAlexakis]

I don't like final either

[vbregier]

I do not think your topic has a lot of interest if you do not explain why you do not like it.

I personnaly like it a lot.
let pi = 4*atan(1);
sounds like a mathematical definition.
This makes a lot of sense to me. pi is defined once, and cannot be redefined. It is therefore a constant.

[DevNoteHQ]

Since Carbon seems to be influenced quite a bit by Kotlin and even aims to do similar things as Kotlin did for the Java world, I'd suggest sticking more to Kotlin syntax.
So for variable declaration var for variables and val for constant values.
I was a bit sceptical of this when I started out with Kotlin, but after using it a bit I have to say that I really prefer it over e.g. TypeScripts let and const.

[zygoloid]

We considered var and val when picking var and let; we were concerned that the visual similarity of var and val would make it harder to read Carbon code than using a more-distinct keyword. Do you find that to be a problem in practice in Kotlin, or is it easy to tell them apart?

Another concern was that var and let are not "siblings" in Carbon -- we intend to allow things like

let (a: i32, var b: i32, c: i32) = (1, 2, 3);

where a variable is allocated for only a portion of a pattern, and for this kind of usage, a val prefix doesn't seem to work so well.

[DevNoteHQ]

If I remember correctly I had like one situation where I got an compiler error because I tried to reassign a val somewhere. But that was more due to me just reading through the code too fast rather then the similarity of the keywords beeing a problem. I would say in general I'm able to tell the difference between the two quite quickly simply because va is the same so you only have to look for the last character and l and r are sufficiently different to spot it right away. Consider this list of variables:

var test1: i32 = 0x1;
var test2: i32 = 0x2;
val test3: i32 = 0x3;
val test4: i32 = 0x4;
var test5: i32 = 0x5;

But that's kind of a non-issue anyway. When reading through code to analyze it's behaviour the difference between a constant value and a variable is ususally irrelevant anyway. And in Kotlins case the IDE will tell you right away when you try to reassign a val or if a var could be a val while writing code so you'll never come in a situation where the visual similarity will cause any real problems.
The reason I don't like let is because it doesn't directly imply from the word itself that this is a constant and because it's used quite differently in different languages. So for example let is a variable in TypeScript, while it is a constant in Rust. And var and val are just quite visually pleasing^^

Now in case of the pattern I would agree that val and var would kind of be weired here. But this is a suboptimal solution anyway. Why not reuse the addr keyword for example here instead of var? Or rename addr to mut and use it here? Maybe with the option to then add another keyword for constant elements so you can write var (a: i32, const b: i32, c: i32)? Altough it seems to be a bit unnecassary to add so many keywords for such a simple problem^^

[vbregier]

We considered var and val when picking var and let; we were concerned that the visual similarity of var and val would make it harder to read Carbon code than using a more-distinct keyword. Do you find that to be a problem in practice in Kotlin, or is it easy to tell them apart?

Has const keyword been considered to define what actually is a constant ?
I think this would make syntax more homogeneous to have var and const.
let and var are very different type of words

[DevNoteHQ]

I've just seen someone suggesting to switch from T:! to T!: for compiletime constants.
In analogy to this, maybe something like ~: could be used to mark one element within a pattern to deviate from the var/let definition?
So for example:

let (a: i32, b~: i32, c: i32) = (1, 2, 3);

instead of

let (a: i32, var b: i32, c: i32) = (1, 2, 3);

This is then also applicable to var:

var (a: i32, b~: i32, c: i32) = (1, 2, 3);

instead of (if this is even considered):

var (a: i32, let b: i32, c: i32) = (1, 2, 3);

[cdmaczane]

This is purely a point about aesthetics, but I like that let and var are the same length and would allow rows of variable names to line up, whether constant or mutable. I suspect this is also one of the reasons to prefer name on the left and type on the right, assuming the name is more important than the type in many cases.

[Tomttth]

var, let and const is surely going to cause confusion for folks who only have javascript knowledge. :)

[GiorgosAlexakis]

After researching it a bit, it does make a lot more sense. Thanks for all the comments.