mutable, const, immutable guidelines

[Daniel Davidson]

On Wednesday, 2 October 2013 at 17:07:55 UTC, Ali Çehreli wrote:
> On 10/02/2013 06:09 AM, Daniel Davidson wrote:
>
> > 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.

Ok - then new guidelines should be added to the effect that, "if 
you want a guarantee of read-only that can be counted on across 
threads, use immutable". But, I'm not sure that is a sensible 
guideline or when you know up-front to deal with it. Often 
threading is an afterthought. My point is not that immutable is 
not useful, but that if you never make an lvalue immutable in the 
guidelines (via guideline 1), it is hard to see them ever being 
used at all. The case in the slides where it was used was to when 
a method required it on a parameter type with mutable aliasing. 
In this case the client was required to copy beforehand. In other 
words, I think even the summary simple guidelines are not so 
simple, maybe because they are incomplete. I would love to help 
complete them.

> Also, an object can safely hold on to a piece of data and trust 
> that it will never change.

I think for this to be true in general, the piece of data must be 
immutable, not just tail-immutable. If the class holds onto a 
string (i.e. only tail-immutable), the class can add to the 
string - just not change the existing characters.

> 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.
>

IMHO file name and ultimately string are the *worst* example :-) 
The reason is they are a special case because they provide *safe 
sharing*. String encapsulates its contiguous data and does not 
allow mutation of elements. But it does allow concatenation that 
by design detail can not be seen by other references to the same 
data because of copy-on-write. Granted, if you have a handle to  
immutable(T)[] you know *it* (i.e. the complete string) will not 
change (unless you change it). The problem is it is just a 
byproduct of the implementation details of immutable(T)[]. From 
the referrer's point of view it is immutable.

For example, the following comparable associative array does not 
have the same benefit as string since two references to the same 
underlying data *do see changes*:

     import std.stdio;

     struct V {
       string s = "I'm a value";
     }

     alias immutable(V)[int] Map;

     void main() {
       Map m = [ 1:V(), 2:V("bar") ];
       Map m2 = m;
       m2[3] = V("moo");
       writeln(m);
       writeln(m2);
     }

The reason I think string is a bad example is one might 
incorrectly assume tail-immutable is good enough for true 
read/only thread-safe data. And it is for string or any 
immutable(T)[], but not in general.


> > 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
>

I can understand - I would not want to put you on the spot on 
stage either. But, I have no qualms doing it in the news groups 
:-)

> 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.
>

Which I wonder if is a good idea. Immediately from that comes the 
problem that "D takes care of it" breaks when you go from no 
mutable aliasing to some mutable aliasing. That mutable aliasing 
could be deep down in the composition chain. I know you can feel 
this issue since your slides point out cases where code may break 
when well encapsulated structs make changes that should not 
impact client code but will break them.

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

Agreed - but post-blits are easier said than done with nested 
data. For instance, if you have a member that is a struct that 
does not provide a post-blit (i.e. the original author did not 
concern himself with sharing) then you have to effectively write 
his post-blit for him in your post-blit. This is why I lobby for 
language supported generalized dup.

> * 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.)
>

I look forward to it and would be glad to help get to a good set 
of guidelines. For instance filling out this, which only covers 
variable declarations - not parameter passing, with a robust 
"when to use".

| context         | T | C(T) | I(T) | I(T)[] |
|-----------------+---+------+------+--------|
| local stack     |   |      |      |        |
| local heap      |   |      |      |        |
| global          |   |      |      |        |
| instance member |   |      |      |        |
| static member   |   |      |      |        |

You could actually have two tables - one for T1 with no mutable 
aliasing and one for T2 with mutable aliasing. But relying on 
that in the decision matrix may lead to issues.

Thanks,
Dan