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