mutable, const, immutable guidelines

[Daniel Davidson]

On Wednesday, 2 October 2013 at 13:09:34 UTC, 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 
> definitely agree it would be helpful to have a 50 Ways To 
> Improve Your D. The first thing I'd like to see is a set of 
> guidelines on mutability along the lines he discussed in his 
> talk. But as it stands, I don't know if there was any 
> finalization/consensus. For instance, from the first two 
> guidelines at the end (after several iterative reconstructions 
> of those guidelines):
>
> 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?
>
> 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 keywords cover all in some sense.
>
> 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 there was back and 
> forth and head-scratching. Another asked if the language 
> designers were happy with the resultant complexity. Naturally 
> the answer was yes - it is a good mix. If that is the case I 
> wonder if the reason is they don't write software in D like Ali 
> was looking to develop. I imagine standard library code is much 
> more functional than OO by its very nature. My money says you 
> will not find a struct S constructed like Ali's in the wild - 
> it is just too much boilerplate. But surely they have their own 
> guidelines/approaches.
>
> 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

After trying for several days to use immutable with types 
containing some mutable aliasing I have come to the conclusion 
that maybe rule number one should be:

If you have a type that has now or may ever have in the future 
any mutable aliasing (e.g. inclusion of T[] or T1[T1] where Ts 
are mutable) do not ever use the immutable keyword in any context 
as things just break down.

If you have had more success with a immutable with types 
containing mutable aliasing and can share your success story that 
would be great.

As D is growing are there any out there yet offering support 
services?

Thanks,
Dan