Discussion: variables const by default

[dkaszews]

Have you considered making variables const by default? I have seen it float around as a recommendation and personally am of the "const everything" camp. It encourages more careful code, catches many errors and makes it more readable (if I see same variable later down the line, I know it has the same value, don't need to check every line in between).

a: int = 3;
a = 5;  // error! implicit const

b: mutable int = 3;
b = 5;  // fine

[tatewake]

The Swift language has two keywords, let for const declarations, and var for non-const declarations.
And Cpp2 seems to have (maybe only coincidentally?) similar syntax for declaring variables, so your example in Swift would be this:

let a: int = 3;
a = 5;  // error! implicit const

var b: int = 3;
b = 5;  // fine

What's also nice is that you get warnings when you declare something as a non-const var when it should be a const let, and changing a let to a var and vice-versa doesn't impact spacing (since both are three-character keywords.)

I get the impression from Herb's talk that he's all about post-fix declarations for everything, but I would hope if he were to do "everything const" kind of decorator / keyword, that it would come first rather than attached to the type.

[dkaszews]

Personally I really like var for (mutable) variable and val for constant value, they are similar enough to show they both introduce a variable, while distinct enough not to mistake them.

I also would prefer keywords for introducing new variables, I found lack of them jarring as it initially looked like introducing new variable is the same as assigning to existing one, though the : T =/:= is distinct from = and lack of keyword may be a context-free grammar requirement.

[JohelEGP]

Personally I really like var for (mutable) variable and val for constant value, they are similar enough to show they both introduce a variable, while distinct enough not to mistake them.

That's way too similar. I don't like lhs and rhs because I often mix them up, so I use l and r instead, and everything is good. var and val will no doubt present this problem for me.

[redradist]

The Swift language has two keywords, let for const declarations, and var for non-const declarations. And Cpp2 seems to have (maybe only coincidentally?) similar syntax for declaring variables, so your example in Swift would be this:

let a: int = 3;
a = 5;  // error! implicit const

var b: int = 3;
b = 5;  // fine

What's also nice is that you get warnings when you declare something as a non-const var when it should be a const let, and changing a let to a var and vice-versa doesn't impact spacing (since both are three-character keywords.)

I get the impression from Herb's talk that he's all about post-fix declarations for everything, but I would hope if he were to do "everything const" kind of decorator / keyword, that it would come first rather than attached to the type.

Rust has much better approach with let and let mut.
Having 2 variant of variables is also not good var and let, because it makes it harder to find all variables for example by pattern in code.
Rust choice is more restricted, because to declare any variable you should do it by writing first let, it means that any variable by default is const.
In Swift it is not a case, it could be var, it is not enforce users to have more const than mut variables

[smallB007]

Sorry to be that guy but the whole "experiment" with new c++ syntax is rather pointless.
We already have that: It is called Rust and does everything and more than cppfront2 is trying to poorly mimic and imitate.
Also, one of main selling points for rust like explicit lifetimes controlled by the compiler - this is simply not gonna happen in cpp. So basically Herb is trying to create/promote knock-off technology that is already outdated...

[jcanizales]

Sorry to be that guy but the whole "experiment" with new c++ syntax is rather pointless. We already have that: It is called Rust and does everything and more than cppfront2 is trying to poorly mimic and imitate. Also, one of main selling points for rust like explicit lifetimes controlled by the compiler - this is simply not gonna happen in cpp. So basically Herb is trying to create/promote knock-off technology that is already outdated...

That viewpoint reflects a lack of knowledge of how the semantics of both languages differ, as well as a misunderstanding of the purpose of this project. But even in a hypothetical scenario in which the languages were semantically the same, the enormous inertia of usage of C++ compared to Rust would make "copying the new syntax over" worthwhile.

[jdbener]

I have seen a similar syntax that uses '=' and ':' to differentiate const and non-const:

x : int = 5; // Mutable
x2 := 5;     // Mutable

y : int : 5; // Constant
y2 :: 5;     // Constant

I think this type of syntax would be more ergonomic in comparison to requiring the "mutable" keyword everywhere. Additionally, making every variable constant would have some implications on backwards compatibility that this sort of syntax elegantly skirts. Alternatively, this type of syntax would add a new teaching point to the language, namely: use ':' over '=' unless you really need the variable to be mutable, which could be argued as being antithetical to this experiment's goals.

[redradist]

@jdbener

I have seen a similar syntax that uses '=' and ':' to differentiate const and non-const:

x : int = 5; // Mutable
x2 := 5;     // Mutable

y : int : 5; // Constant
y2 :: 5;     // Constant

I think this type of syntax would be more ergonomic in comparison to requiring the "mutable" keyword everywhere. Additionally, making every variable constant would have some implications on backwards compatibility that this sort of syntax elegantly skirts. Alternatively, this type of syntax would add a new teaching point to the language, namely: use ':' over '=' unless you really need the variable to be mutable, which could be argued as being antithetical to this experiment's goals.

As for me, it is unreadable ...
What is readable it something like this:

num: int = 0; // Immutable
num := 0; // Immutable

num: mut int = 0; // Mutable 
num : mut = 0; // Mutable

[hsutter]

I mostly agree with const by default... I've now written up my thoughts about this in Design note: const objects by default.

[redradist]

@hsutter

I mostly agree with const by default... I've now written up my thoughts about this in Design note: const objects by default.

From my practice developers usually forget to add const modifier and not vice versa.

Adding const by default could bring the following benefits:

1. Increase readability (by some measurements we read code 10x longer than writing), and developer who will read code will be easier to reason about mutable variables
2. Could prove code correctness like it was done in Rust. By making all variables const by default a static analyzer should perform less work and also a static analyzer would be much simpler
3. Could prevent from potential race-conditions, it is simpler to reason about small chunk of mutable variables
4. Improve code generation. C++ optimizer will say thank you for adding more const :)
5. ... and others

[ruler501]

Const by default everywhere has the issue of inhibiting move semantics which can be a major performance issue.

[JohelEGP]

It should be possible to respecify how move semantics work in a Cpp2 with const by default.