const

[Georg Wrede]

Walter Bright wrote:
> Bill Baxter wrote:
>> Again talk about potential is great, but until I've seen something 
>> more concrete I'm very skeptical that adding a dash of invariant 
>> into the mix is magically going to make D a multi-core champion.  I
>>  suspect it will require very careful use of invariant in the parts
>>  of code you want to make parallel, and so it won't be just a 
>> magical switch that suddenly makes all your code run 10x faster. 
>> It'll be something that requires careful planning to take advantage
>>  of.
> 
> I fully agree that invariant by itself doesn't magically turn D into 
> a multiprogrammer's dream. But invariant is a crucial brick in 
> building multiprogramming support. The lack of it is why C++ will 
> never be easy to use for multiprogramming.
> 
> We're just on the cusp of a huge push towards multiprogramming. We 
> have to be ready for it, or we'll be left in the dustbin of history.

I massively agree here. While I've said that I personally don't use
const, I still think pursuing const, const-correctness, and const
transitivity are definitely a top priority for D.

My take on it is, _because_ const transitivity is _hard_ to patch onto
C++, Java, etc., _and_ it seems to be within reach for D, that alone is
reason enough to give it our best shot. (If it turns out later that not
even we can do it, then so be it. But 5 years from now, we'd crucify
ourselves for not having tried, if it turns out it's been done in any of
those languages, even half-bakedly.)

And, once we get it right, I'd be surprised if not almost everyone here
starts using it as a matter of course. When it works and is not unduely
obtrusive to use, I think most would agree that it's the Right Thing to
do, even in small projects. (Using the same MO everywhere is easier than
up front deciding wether this'll be a big or a small project.)

Plus, when teaching classes, const would then be taught right after the
concept of functions, and way before recursion or linked lists.


=== mostly off-topic ===

>> The long-standing enhancement request asking for const in Java was 
>> closed by Sun as "will not fix"[1].  They don't seem to think it's 
>> a show-stopper.
>> 
>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070
> 
> Java can't fix it and be backwards compatible. They're stuck. If they
> had a chance of a do-over, I have little doubt they'd go for 
> transitive const.
> 
> The pressure to add const to Java comes up again and again. It's not
> going to go away, and it's just going to get worse.

Since Java is only on a VM (the last physical CPU to run Java natively 
was, I guess, my Java Ring that I got from a convention, years ago...), 
it is interesting that they didn't run multithread stuff already in the
nineties on a regular basis to get experience on multithreading.

How hard can it be to write a two- or even eight-virtual-processor VM?
Basically all you need is a 386 (albeit "overclocked"). The VM would of
course fake the multi thing, but still.

Would've given them a head start.