mutable, const, immutable guidelines

[Ali Çehreli]

On 10/02/2013 06:09 AM, Daniel Davidson wrote:

 > I'm reviewing Ali's insightful presentation from 2013 DConf. I
 > wonder has he or anyone else followed up on the concepts or
 > formalized some guidelines that could achieve consensus.

I have not followed up on those concepts.

 > 1. If a variable is never mutated, make it const, not immutable.
 > 2. Make the parameter reference to immutable if that is how you will use
 > it anyway. It is fine to ask a favor from the caller.
 > ...
 >
 > If you follow (1) exclusively, why the need for immutable in the
 > language at all?

For one, immutable is thread-safe. Also, an object can safely hold on to 
a piece of data and trust that it will never change. A file name is a 
good example: An object need not copy a string that is given to it as a 
constructor parameter. That string will be immutable as long as that 
reference is valid.

 > Maybe it is a philosophical question, but where does
 > immutability really come from? Is it an aspect of some piece of
 > data or is it a promise that function will not change it? Or is
 > it a requirement by a function that data passed not be changed
 > by anyone else?

The two concepts are necessarily conflated in languages like C++ because 
for those languages there is only the 'const' keyword.

D's immutable is the last point you made: a requirement by a function 
that data passed not be changed by anyone else?

 > I found the end of the video amusing, when one gentleman looking at a
 > rather sophisticated "canonical" struct with three overloads for
 > 'this(...)' and two overloads for opAssign, asked if all those methods
 > were required.

I think you are referring to Ben Gertzfield's question. He later told me 
that he was sorry that he asked the wrong question at the wrong time. :D

To be honest, that slide was added more as an after thought. I suspect 
that that canonical struct is simpler today after changes made to dmd 
since the conference. (I will look at it later.) For example, there are 
no 'pure' keywords around in that code. I think the (ability to) use of 
that keyword will simplify matters.

However, I should have answered Ben's question by the following:

* If the struct is simply a value type or has no mutable indirections, 
no member function is really necessary. D takes care of it automatically.

* Sometimes post-blit will be necessary for correctness. For example, we 
may not want two objects share the same internal buffer, File, etc.

* As noted in the presentation, the default behavior of struct 
assignment in D is exception-safe: first copy then swap. In some cases 
that automatic behavior is less than optimal e.g. when an object's 
existing buffer can be reused; no need to "copy then swap (which 
implicitly destroys)" in that case. (The spec or Andrei's book has that 
exact case as an example.) So, opAssign should be for optimization 
reasons only.

(I will look at these again later.)

 > By posting this I am not looking for a single answer to the simple
 > question above as it is just one of many questions in the set of "how do
 > you choose among the options in general". If you have such guidelines -
 > please post them.
 >
 > Thanks
 > Dan
 >

Thanks for asking these questions.

Ali