const or immutable?

[Ali Çehreli]

On 9/22/21 6:29 PM, Mathias LANG wrote:

 > I think we should not fall for the fallacy of "more attributes == good".

In addition to what you say, complexity in a tool is detrimental for 
adoption, usability, undestandability, maintenance, etc.

 > I don't think it's [that simple](https://youtu.be/qx22oxlQmKc?t=923).

Excellent presentation. I have always respected Herb Sutter, am jealous 
of his methodical approach to problems, and happy to have met him at SD 
2000 to chat briefly while having his book signed.

Although most of what he presents is either already in D or discussed 
for D, he (and many other great minds) are still working for improving 
C++. I don't approve his ignoring D in the context of that talk; he 
lists just two of more popular languages (C# and Ada). If his proposal 
is ever finds its way into C++, it will be again "other languages are 
taking from us but they never acknowledge it" (what I remember from past 
a Bjarne Stroustrup keynote speech). It takes a different kind of 
personality to realize that all improvements that one is thinking for 
C++ is already in D and to see it reason enough to put efforts in. (I 
know Herb Sutter knows about D because he has been rubbing shoulders 
with Andrei. He was a co-author of a proposal to add D's 'static if' for 
C++, where D was referenced.)

I like how he says "I can't teach it. It's too complicated." Exactly! 
That's why I am here on this thread.

Some of what he presented relates to D:

- in, out, and ref

- Some of Walter's efforts for @live (when proposed improved C++ 
compilers analyzing flow graphs)

- In a D constructor, initialization is "first assignment".

- " = void"

 > Our guidelines were simple:
 > - Template Parameter ? => `istring`;

Of course, manifest constants (e.g. enum) as well.

 > - `const`: Cannot be modified through this instance;
 > - `immutable`: Cannot be modified through *any* instance;

Allow me to stay on an unnecessary detail: Those are very common 
definitions that are repeated elsewhere in this thread. However, partly 
encouraged by Herb Sutter's stressing "intents", I will explain my 
different take on it: Parameters are parts of a contract between the 
function and the caller; they must be described from the function's 
point of view:

- When a function parameter is 'const', it is the function's telling to 
the caller "I promise I will not mutate it". (And of course the compiler 
enforces it.)

- When a function parameter is 'immutable', it is the function's telling 
to the caller "I require immutable (with the literal meaning here)".

Perhaps not an important difference but I think such details are 
important for teachability.

And there is a difference between parameters and variables because the 
latter is not a requirement like it is for functions. TO me, an 
'immutable' variable carries a meaning for it to be required to be so; 
'const' does not have that meaning for a variable. That's why I like 
'const' for variables like the following:

   const     a = 42;  // Simple
   immutable b = 42;  // Brings more meaning and supposition

Ali