Optimizing Immutable and Purity
SeeWebsiteForEmail at erdani.org
Wed Dec 24 08:45:22 PST 2008
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.
> At least for the current D2, your statement is very wrong.
> 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
> 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
> The bottom line is that const gives no guarantees.
See the example in my other post.
More information about the Digitalmars-d