const?? When and why? This is ugly!

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Mar 2 09:25:57 PST 2009


grauzone wrote:
> You probably mean that data shared between threads has to be immutable. 
> Then all threads can access that data without synchronization. 
> Immutability will sure be useful here: the type system guarantees, that 
> data can never be modified. But how does this work for complex types 
> like objects? Is there an idup for objects? Does it do a deep copy of an 
> object graph? How is communication between threads supposed to work? 
> Shouldn't all global variables be immutable then? Please, where can I 
> find complete, thought-through concepts?

You cannot find them yet because the thinking-through process is still 
ongoing.

> Does this approach fit D at all? D is a C based system programming 
> language. Does it work to demand from everyone to obey the const rules? 
> Couldn't all this be done manually, instead of bothering the programmer 
> with a complex type system?

C is still having trouble removing those pesky buffer overruns. Writing 
a large manycore application in C will be anything but casual programming.

> Sometimes, you have to leave the more spiffy features to languages like 
> Erlang or Haskell which are suited better for this. For example, Erlang 
> doesn't share any state by default, and in Haskell, everything is 
> immutable. But they use very special mechanisms to make up for the 
> problems caused by this, and that's why you can't just pick the 
> cherries: it won't fit, it will feel unnatural, and everything will be a 
> mess. It's a good idea to copy good features from other languages, but 
> never forget where you come from.

We plan to add the necessary mechanisms.

> Regarding pureness: I don't think it has anything do to with locking. A 
> function could just take const arguments, and everything is safe. It 
> can't write to shared data either, because shared data is supposed to be 
> immutable, right? In this context, it doesn't matter if the function 
> writes to anything else, because that data will be thread local.

Not all shared data is immutable. Data marked as "shared" is shared. The 
cool thing is that D switches the default to the "right" default.

The style of programming in which you create a new thread that joyously 
sees and can modify *all* of the memory space available to every other 
thread will go the way of the dinosaur. It's just not tenable anymore, 
and I predict today's mainstream programming languages abiding to that 
model are facing major troubles in the near future.


Andrei



More information about the Digitalmars-d mailing list