const?? When and why? This is ugly!

[grauzone]

Jason House wrote:
> grauzone Wrote:
> 
>> dsimcha wrote:
>>> == Quote from hasen (hasan.aljudy at 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.