immutable, const, enum

[Derek Parnell]

On Tue, 28 Apr 2009 14:08:58 -0400, Steve Teale wrote:

> bearophile Wrote:
> 
>> I am about one year late for such comments or more. I also have some suggestions and questions.
>> 
>> I suggest to perform a serch & replace in all the D2 documentation to replace all "invariant" with "immutable". Some versions of D2 from now "invariant" can be removed from DMD itself.
>> 
>> -----------------
>> 
>> From the examples of the docs. I hope to not see this code, it's not easy to understand:
>> immutable(char*)** p = ...;
>> 
>> -----------------
>> 
>>>The const and immutable function attributes can also appear after the closing parenthesis of the parameter list: <
>> 
>> I think this doesn't produce much damage, but why?
>> 
>> -----------------
>> 
>> Mutable and transitive-immutable data types are easy to understand. But "const" is less easy to understand for me:
>> 
>>>Const types are like immutable types, except that const forms a read-only view of data. Other aliases to that same data may change it at any time.<
>> 
>> Regarding its purpose the docs say just:
>> 
>>>const finds applications in passing data through interfaces that promise not to modify them.<
>> 
>> I suggest to add more examples of "const" usage, to show where it can be useful, because I am not much able to understand where to use it.
>> 
>> It may also be better to rename "const" of D2 as "constview" or "cview" then (and the meaning of const can be kept from D1).
>> 
>> The semantic overloading of the "enum" keyword doesn't look nice, but it's not too much bad.
>> 
>> -----------------
>> 
>> The following things are written about constview/immutable member functions:
>> 
>> immutable member functions are guaranteed that the object and anything referred to by the this reference is immutable. They are declared as:
>> 
>> struct S {
>>     int x;
>> 
>>     immutable void foo() {
>>         x = 4;	    // error, x is immutable
>>         this.x = 4; // error, x is immutable
>>     }
>> }
>> 
>> constview member functions are functions that are not allowed to change any part of the object through the member function's this reference. 
>> 
>> I don't understand such explanations, and I'd like to see a bit wider example(s) about it.
>> 
>> -----------------
>> 
>> Immutable structs/classes can be quite useful, they are safer, remove some complexity from a program, they can be sometimes the right thing you want (think about a Date object that keeps one day of the year), help paralellism, and they may allow for other optimizations (for example there's no need to copy them (so you can save memory and/or allocations, just like for immutable strings), or on the opposite you can have a copy of them on each CPU cache, and you are sure they will not go out of sync, this allows for a program more scalable on multi-cores).
>> 
>> So I have tried to write a very simple program that uses immutable structs and classes:
>> 
>> immutable struct S {
>>     int x;
>>     this(int xx) { this.x = x; }
>> }
>> 
>> immutable class C {
>>     int x;
>>     this(int xx) { this.x = x; }
>> }
>> 
>> void main() {
>>     auto s = S(10);
>>     auto c = new C(10);
>> }
>> 
>> But the compiler outputs:
>> 
>> Error: cannot implicitly convert expression (this) of type immutable(C) to test.C
>> test.d(8): Error: constructor test.C.this missing initializer for final field x
>> test.d(12): Error: constructor test.S.this (int xx) does not match parameter types (int)
>> test.d(12): Error: ((immutable immutable(S) __ctmp1 = 0;
>> 
>> ) , __ctmp1).this can only be called on a mutable object, not immutable(S)
>> 
>> I don't understand such errors much. What is that I am doing wrong?
>> Note that if you remove the "immutable" that program works, and if you replace "immutable" with "invariant" the compiler gives thye same errors (internally it keeps using immutable(C)).
>> 
>> Thank you,
>> bye,
>> bearophile
> 
> Well, I'm glad it's just not me! Anytime I've used the keyword 'invariant' what I get just won't compile. So I remove it, which suggests that from a practical point of view, it is not much use.
> 
> Const for me should mean pretty much what it means in C++
> 
> If I write:
> 
> foo(const Bar b)
> {
>    // I mean that if in my implementation of the function, I try to alter
>    // b, then the compiler should flag it as an error.
> }
> 
> foo(invariant Bar b)
> {
>    // Does not seem to offer anything else that I need!
> }

The difference between immutable and const, in my understanding, is that
'immutable' means that nothing in the program will change it, and 'const'
means that this function won't change it but it might be changed by other
functions in the program.

What has surprised me is that immutability is *not* guaranteed. It is also
just a promise that the coder makes to the compiler. You can declare
something as immutable and have the program change it. The compiler does
not actually prevent that happening, it only makes it difficult to do. Same
with const.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell