On Friday, August 13, 2010 14:10:20 Tomek Sowiński wrote: > Glad you like it. Time ago I had an overzealous attempt to port QuantLib to > D and I quickly found out that the *only* sort of const I needed was tail > const. It's what I ended up declaring fields of my structs because if just > one field is from-head const, the restrictions are basically the same as > if the whole struct was const (which is correct but...). It's what the > parameters of pure functions should implicitly be declared to (no big > deal, but still). From-head const gives me no upper hand in the > multi-threaded domain, just pain in my rectum domain. Sure, from-head > const is at times useful, but tail const is the workhorse.
That's exactly why final in Java is so useless for objects. It makes the wrong thing const. How often do you have const pointers in C++? Very rarely. How often do you have pointers to const in C++? All the time (assuming that you're trying to be at all const-correct anyway). At the moment, D is falling into a pit similar to that of Java with const and references. D's is better since the object _is_ const, but since you usually just want the object const, not the reference, it's incredibly counter-productive. - Jonathan M Davis
