Jason House wrote:
grauzone Wrote:
dsimcha wrote:
== Quote from hasen (hasan.alj...@gmail.com)'s article
Uhh, that's what aliases are for. The string alias is defined automatically in
object, and string is an alias for immutable(char)[].
That Phobos introduces this alias is not really an argument that speaks
in favor of the syntax.
Also, I don't quite understand yet what constness is good for. While it
seems to be a good idea, it seems to be more an annoyance in practice.
It doesn't seem to pay off. What is this additional complexity for? And
really, what was wrong with not having constness? All I hear is
something about threading, but I didn't see anything convincing yet. No
real examples, not even a full concept. Only some loose arguments. Come
on, the newest compiler releases can do const, now convince me already
that it's a good feature!
Given the tone of your messages, I assume convincing you is impossible. The biggest help
I can offer is to tell you that "the D you loved" still exists as D 1.0...
Walter still maintains the compiler for it and Tango, Descent, GDC, LDC, and many other
things all support D1.
Forgive me, I always get the tone wrong. As for the "D you loved",
please don't assume things. I think D2.0 is a huge improvement over
D1.0. But of course, there are always some issues. Nothing is perfect,
after all.
And actually, I'm not opposed to these new (actually old) ideas. I just
want more information. And yes, I don't like the current const
mechanism, because I think it introduces complexity for no gain. That's
why I'd like to know more in the first place.
And I think I'm not the only one who would prefer to see ast macros to
be implemented rather than const.
Regarding pure functions: isn't CTFE already enough?
The big driver of D2 is provably safe multithreading without locks. Pure functions are the embodiment of that, and immutable data is required for that. Const is used to handle either mutable or immutable data.
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?
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?
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.
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.
This rather seems to have to do with optimization by caching results,
and with automatic parallelization. Well then, I want to see how this
can be applied in D! Again, forgive me my tone. I mean, it's not like
I'm threatening anyone or that I want to start flamewars, I just want to
know more about this.
Does that help?
Not really. I just wasted time by writing this post, and probably the
time of people who read this post. It's a shame.
