use `let` keyword instead of `const` for immutable variable declarations

[andrewrk]

Currently, we have const and var for variable initializations.

const means that the bytes directly referenced by the variable cannot change after this assignment.
var means that they can.

Previously we had copied Rust and had let and let mut. See #34.

@procedural has suggested renaming const to let.

@thejoshwolfe says:

Where's the burden of proof here?
const means it doesn't change, which matches the behavior of a const declaration. let is used in javascript and other languages for any kind of local variable

One argument for let over const is that it's the same length as var and thus as easy to type. In general the language is supposed to guide the programmer into doing the Right Thing, which is to default to using const/let for as many things as possible instead of var.

One argument for const is that it matches the syntax of C, C++, and JavaScript.

In this issue, let's figure out How It Should Be and make a decision. Then once the decision is made we can refer people to this issue.

[andrewrk]

Also relevant is #83. "...if we had this different return value syntax, it implies that we should support tuples..."

If we had tuples, then we may consider following Rust's lead and having let and let mut so we can do things like let (mut a, b) = foo().

Can we support both? Like, let x = ... will be the same as const x = ...? Because I don't want to see [] const u8 string be written like [] let u8, but I also don't want to type const x = ... for every immutable variable I declare (in Swift, I used let everywhere, so typing it does matter, at least for me)

I think removing const will make at least some people angry, so ideally we need both, let as a shortcut for const for people who don't want to type it for variable declarations. Zig is is fine having multiple shortcuts for error handling anyway, so why not add just one that saves typing for the most common operation. And if not adding let at all, well, there's 33K of people who liked Swift on Github, more than Rust or Go, some of them may consider Zig at some point, providing them a familiar syntax can make them happier.

[andrewrk]

Having two ways to do the same thing goes against the principle of One Way To Do Things, which exists to support the goal of readability. Uniform code is more readable.

It's OK to have both the let and const keywords exist, but there would not be two ways to do a variable declaration. For example one possibility is that every variable declaration must be let x = ... but const is still used for type qualifiers like []const u8.

Zig is is fine having multiple shortcuts for error handling anyway

Not quite. I'm considering removing the %return ... operator in favor of requiring ... %% |err| return err for just this reason. But, even if zig ends up keeping %return ..., then it will be idiomatic to use %return when you can rather than the longer ... %% |err| return err form.

33K of people who liked Swift on Github, more than Rust or Go, some of them may consider Zig at some point, providing them a familiar syntax can make them happier.

Both Swift and Rust use let and I agree that is an argument in favor of let over const.

For example one possibility is that every variable declaration must be let x = ... but const is still used for type qualifiers like []const u8.

That would actually be perfect imo!

[phase]

From an ML perspective, let is used as a binding between a name and a value, and is usually constant. OCaml uses let x = ref 1 for mutability, which isn't really changing the value underneath. It's reference to a value. Using var and let together could be nice, or you could just make everything immutable.

For tuples, do we really want to allow assigning mutable and immutable data in the same statement? That seems like a little much.

// This is too busy.
let (mut a, b) = foo()

// These are clean.
let (a, b) = foo()
var (c, d) = bar()

I don't like two keywords for assigning a variable. var is short for variable, or vary. The value of variable may change. let is a declaration, stating that this will never change (unless you allow variable shadowing).

[felipecrv]

JavaScript now has let (local scope), var (function scope) and const (local scope const). It is a mess.

You most likely want to use const most of the time, it is the hardest to type and it adds too much noise. let is not used for defining constants in every language, so it is not the least confusing keyword.

I suggest zig to copy Scala on this: use val and var.

use val and var

The letters are too visually similar... One last character determines the whole chain of surprising consequences...

let is used as a constant variable declaration by two of the most popular statically typed and compiled languages known today: Rust and Swift. When people get burned by their slowness they'll look for an alternative which will be a language close to the compile speed of C. Zig is the best alternative so far, and it's better be familiar to them in general cases like variable declaration, in my opinion...

I've updated the patch, trivially made an exception for [] const and & const qualifiers. To try it out:

git clone https://github.com/andrewrk/zig Zig
cd Zig
git checkout f18e34c
cd ..
wget https://gist.githubusercontent.com/procedural/9443f1a5353e158a4422ecc397a96740/raw -O zig_const_to_let.patch
cd Zig
patch -Np1 < ../zig_const_to_let.patch
mkdir build
cd build
CC=clang CXX=clang++ cmake .. -DCMAKE_INSTALL_PREFIX=$(pwd) -DZIG_LIBC_LIB_DIR=$(dirname $(cc -print-file-name=crt1.o)) -DZIG_LIBC_INCLUDE_DIR=$(echo -n | cc -E -x c - -v 2>&1 | grep -B1 "End of search list." | head -n1 | cut -c 2-) -DZIG_LIBC_STATIC_LIB_DIR=$(dirname $(cc -print-file-name=crtbegin.o))
make && make install && cd lib/zig/ && find -type f -print0 | xargs -0 sed -i s_"const"_"let"_g && cd ../..

[andrewrk]

Let's make a language table for how to declare a single assignment variable.

  Language | Syntax for single assignment
  ---------+-----------------------------
 C, C++, D | const
      Rust | let
     Swift | let
     OCaml | let
JavaScript | const
     Scala | val
      Java | final
       Nim | let
        Go | = / :=
    Pascal | = / :=

Any others we should add?

[phase]

Implicit declaration is an option.

a = 7;

And we could use a keyword for immutables.

const a = 7;

a = 7;

Now it's no different than assignment, isn't it? :)

[andrewrk]

I veto implicit declaration. First of all if there were implicit declaration the default should be immutable, not mutable. And then as far as parsing goes, it's easier to parse for both humans and computers if there is a keyword to indicate that a constant is about to be declared.

And then importantly, in this situation:

var a: i32 = 0;
fn f() {
    const a = 7;
}

We get a compile error saying that we shadowed a. With implicit declaration we would accidentally override the value a with 7.