I just got it! (invariant/const)

[Jason House]

They say the best way to learn is to explain to someone else... 

Many have said FP style multithreading requires pure functions with invariant data. The strange thing is that pure functions can't call invariant member functions of their invariant data. Why would that be? That's especially strange when the justification for invariant is multithreading.

I've been arguing for a while that mutable access to globals is like head const and kills most of the benefits from the const system. Please help me understand why I am wrong.

Lionello Lunesu Wrote:

> After reading Walter's posts these last weeks and Andrei's PDF, I think the 
> D 2.0 invariant/const make a lot of sense, and I can see the how it opens up 
> new possibilities.
> 
> I was a bit worried for a performance penalty because of the need for 
> "idup"s, but then I realized that you only .idup when you use "invariant()" 
> when you actually don't care about it being invariant or not. So converting 
> all D 1.0 "char[]" to D 2.0 "string" might not be such a good idea.
> 
> One thing that I like is that suddenly C++ "const &" construction can be 
> standardized and made safe at the same time! Because of invariant, "in" can 
> safely pass the arguments by ref, instead of by value.
> 
> Sorry for repeating what most probably already know, but it just felt like a 
> revelation that I had to share :-)  A bit slow perhaps, but I'm pretty sure 
> I'm not the last one to /get it/.
> 
> Thanks Walter, Andrei for explaining this invariant/const thing over and 
> over again, in different forms.
> 
> Now I'll have to change Phobos 2.0 to get "foreach(string s; new 
> BufferedFile(..))" working ;-)
> 
> L.
> 
>