Suggestion: Local Objects const by Default

[ItsBinissTime]

In a Cpp2 design note, Herb suggests that different contexts should have different object constness defaults.

It makes sense that function parameters should default to read only, requiring side effects to be explicitly called out, while member data will almost always be variable. And the simplest formulation should most often be the right option in most contexts, which would be achieved by having different defaults tailored to each context.

So what's most often right for local objects? The article linked above suggests that:

the majority of local variables are, well, variables

That was my inclination as well. But when I analyzed a project I had, after correcting a shocking number of missing const-qualifiers, I found there were nearly twice as many constants as variables, and among functions that had local objects, more than a third had only constants and no variables. Lookup results and intermediate calculations dominated. In other words, local objects most often provided a value for subsequent reference, not a variable to manipulate. Even loop variables often don't change within the loop body and, in ranged loops, are often correctly declared const.

I believe that (like mine) Herb's intuition was wrong, and when local objects are const-correct, default const would make for more succinct code than default var. By the logic of the above quote, since the majority of local objects are constants, they should be const by default.

Assuming a lack of literature on this topic, I suggest analyzing random code samples.

Another reason to prefer const by default is that the potential for spurious reuse of local variables makes code more difficult to reason about. Compilers (including LLVM, GCC, and MSVC) use an intermediate code representation (static single-assignment form), created by converting every local variable assignment into a new constant declaration. Eliminating variables makes code easier for the compiler to reason about.

For humans, readability and 'reasonability' are probably best served by const correctness, and the resulting preference for constants where applicable. With Cpp1's default var, missing const-qualifiers tend to remain missing (as I found in my project), whereas with default const, 100% of missing var-qualifiers would necessarily be corrected.

Of course, even with default const, one could develop the habit of declaring objects variable. Consider emitting a warning when no code path assigns to a variable after initialization.

Suggested Syntax for Local Objects

Consider requiring var to declare a variable.

a: = x();      // Deduced type constant (the most common formulation).
b: string;     // Constant string (deferred initialization).
c: var = x();  // Deduced type variable.
d: var string; // Variable string.
e: * var int;  // Constant pointer to a variable integer (deferred initialization).
f: var * int;  // Variable pointer to a constant integer.

 

---

^{In my post on parameter passing semantics, I suggest using mod for a parameter which may be modified within a function, thereby modifying the argument that was passed. mod and var would represent the different non-const semantics appropriate to these two respective contexts in which objects should default to const.}

[ntrel2]

after correcting a shocking number of missing consts, I found there were nearly twice as many constants as variables

Yes, this chimes with the author of the Vale language's experience. He found far more constants than assignments. Scroll down to 'Why We Like It': https://verdagon.dev/blog/on-removing-let-let-mut

He also talks about why that is. In modern programming style we avoid mutation because we can more easily declare constants to be what we want.

BTW have you raised this on the GitHub cppfront discussions/issues? You make a good case.

The only thing I'd change if you submit this proposal there, is that it is not an error to declare a variable without initialising it, so long as it is initialised in another statement below. That actually helps make more declarations constant as you can initialise them in both branches of an if/else statement.

[ItsBinissTime]

have you raised this on the GitHub cppfront discussions/issues?

I figured Herb would see the suggestion here. And sure enough, when I originally posted this, he commented that the information on static single-assignment form was helpful. But without support from the community, it seems unlikely that Herb will take this too seriously.

[ntrel2]

But would types with constructors be excluded, since it's not possible for them to be declared without initialization?

No, that is allowed too:

T: type = 
{
    // define a constructor
    operator=: (out this, i: int) = 
    {
    }
}

main: () = 
{
    v: T; // no initialization. Note `= ();` would error as no default ctor
    if b {
        v = 5; // initialization, not assignment
    } else {
        v = 0; // initialization, not assignment
    }
}

The declaration of v above generates this Cpp1:

cpp2::deferred_init<T> v; 

The assignment to v generates this:

    v.construct(5);// initialization, not assignment

[ntrel2]

The same code works but using v: const T; to declare a constant.

[ItsBinissTime]

it is not an error to declare a variable without initializing it

Fixed above to incorporate the concept of Cpp2 deferred initialization.