thoughts on immutability in D

[Rainer Schuetze]

On 9/24/2011 3:00 PM, Peter Alexander wrote:
> On 24/09/11 9:46 AM, Rainer Schuetze wrote:
>>
>>
>> On 9/24/2011 9:30 AM, Andrei Alexandrescu wrote:
>>> On 9/24/11 1:12 CDT, Rainer Schuetze wrote:
>>>>
>>>> On 9/22/2011 4:10 PM, Andrei Alexandrescu wrote:
>>>>> On 9/22/11 3:02 AM, Peter Alexander wrote:
>>>>>> On 22/09/11 7:04 AM, Andrei Alexandrescu wrote:
>>>>>>> The initial submission got junked so I resubmitted:
>>>>>>>
>>>>>>> http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Andrei
>>>>>>
>>>>>> Thanks for the reddit'ing. I launched up google analytics this
>>>>>> morning
>>>>>> and noticed a sudden spike. That could only mean one thing :-)
>>>>>>
>>>>>> Out of interest, does anyone have any criticism of my post, esp. if
>>>>>> there's any technical inaccuracies (or just disagreement?)
>>>>>
>>>>> You could have specified that e.g. mutable state can be implemented
>>>>> safely with the help of a global hash table.
>>>>>
>>>>> Andrei
>>>>
>>>> If this is allowed by the compiler, doesn't that break all the
>>>> guarantees transitive immutability tries to make? Aren't we back to
>>>> "faith based programming" this way?
>>>
>>> Not at all. Global mutable memory is what it is to everyone.
>>>
>>> Andrei
>>
>> I'm probably missing something, but what are the guarantees given by the
>> type system, if a property is implemented by a getter function:
>>
>> int globId;
>>
>> class C
>> {
>> @property id() const { return ++globId; }
>> }
>>
>> int main()
>> {
>> immutable(C) c = new immutable(C);
>> return c.id;
>> }
>>
>> Is c.id thread-safe? no! Is it constant? no! How does this help in
>> multi-threaded applications that access c?
>
> It is thread safe. globId is a thread-local variable.

sorry, I noticed this mistake in my example too late. Using shared(int) 
still compiles:

shared(int) globId;

class C
{
	@property id() immutable { return ++globId; }
}

int main()
{
	immutable(C) c = new immutable(C);
	return c.id;
}

Please notice, that I have also changed "const" to "immutable".

>
> It *is* constant (the C object isn't modified) put it isn't *pure* (the
> return value isn't consistent).

Yes, that's my point. What is actually guaranteed by the type system to 
a thread that works on an instance of type immutable(C)? It is not 
thread safety or constancy when reading properties, that would require 
them to be pure.

>
> However, the fact that it is constant is just a fluke. For example, you
> could do this:
>
>
> C globalC;
>
> class C
> {
> int x = 0;
> this() { globalC = this; }
> int getX() const { globalC.x++; return x; }
> }
>
> C c = new C();
> writeln(c.getX()); // 1
> writeln(c.getX()); // 2
> // etc.
>
>
> const (on its own) has *no* guarantees. It doesn't guarantee a
> consistent value (that's what pure is for) and it doesn't guarantee that
> the object isn't modified (that's what immutable is for).
>
> All const does in D is provide a bridge between T and immutable(T).