Optimizing Immutable and Purity

[Andrei Alexandrescu]

Jason House wrote:
> Andrei Alexandrescu Wrote:
> 
>> Walter Bright wrote:
>>> Andrei Alexandrescu wrote:
>>>> Const is still useful because inside a function you know for
>>>> sure that another thread can't modify the data.
>>> I think you meant immutable.
>> I meant const.
>> 
>> Andrei
> 
> At least for the current D2, your statement is very wrong.

Yah.

> For
> function calls, const is merely a promise by the callee to not modify
> the data or call non-const member functions. Any data can be passed
> into the function. That means that mutable references can exist
> through other threads, global variables, or through other input
> parameters. Const data can change at any time.

In D2, threads will be effectively memory-isolated. Walter, Bartosz, and 
I are convinced that this is a very solid model to start with. Sharing 
among threads will be explicit by means of a "shared" type constructor. 
Everything else will be unshared. This is in contrast with the C, C++, 
and Java model in which all threads share memory indiscriminately (and 
it's up to the programmer to painstakingly ensure that no undue sharing 
is happening and that all sharing is properly synchronized). I think 
that model will go the way of the dinosaur.

For const, this means that const data can be assumed to be modified 
through aliases in the current thread, but not in other threads. So if 
the compiler proves no aliasing for a code region, const is as good as 
immutable.

> Even if we jump forward to a D2 where only shared const can be
> modified by other threads, the guarantees are not much better. Every
> impure function call can modify the data. That includes const member
> functions of const data! I've complained about that last bit many
> times.
> 
> The bottom line is that const gives no guarantees.

See the example in my other post.


Andrei