I'm not sure if the current way const is heading is for better (read,
more productive, i.e. safer and /faster/ ) programming, or if it is for
better compiler omtimizability in a multithread+multiprocessor setting,
forgetting the poor programmer.
Of course, the holy grail would be getting both, but I'm not so sure
that is even within reachability of D2. Maybe D3, though? In that case
should we try to get there one step at a time? But then, where should we
draw the line on how far we try to get with D2?
---
Im' not familar with, so does anybody know of any texts available on
statistical properties of existing major codebases? Like how often does
a variable get reassigned more than once in a program, or how often does
a reference or a pointer get reassigned, with or without regard to if
data has been changed via it.
And if such data (or academic papers) don't exist, then MIT and others
sure as hell should start looking into it. There's enough source code
for C and C++ on any Linux source distribution dvd, for Java there's at
least OpenOffice source, and Python and other languages also are
options. And some of the lessons learned most probably go for the whole
spread of "our sister" languages as such.
---
Thinking about this also gives some ideas. Like, suppose "a C like
language" decides to skip const altogether, and instead rely on the
compiler simply checking whether a variable is assigned to once, or more
than once in the code. This might even be as simple as grepping for
assignments to the variable(1). And if it turns out it's only once, then
the variable could be invisibly flagged as de-facto-const, and the
compiler could then optimize it for MT and/or MP stuff, to its heart's
content.
Such a compiler, or even an external tool, could give the programmer a
list of all variables that are assigned more than once in the entire
application, with filenames and line numbers.
Of course, in a Systems Language, there always are Intractable Ways to
change data, but such a list could be invaluable for the conscientous
programmer. Also *SafeD* might benefit even more from this list.
Chances are many programmers who currently don't use const, or who'd
like to omit it, might even pay money for such a feature.
---
(1) Well, grepping might be a bit of an over-simplification. But, a
compiler might have a switch to output a version of the program (a
little like today's debugging or profiling switches) that actually
writes a list of reassignemts. (Such a program version might even look
at memory changes, and then report based on which variable owned that
particular location, report stats. (Already Turbo Pascal 2.0 did
something similar with runtime crash reports.) This might be easier than
keeping track of variables and assignments, for all I know. Besides,
then the facts are right, no matter how obscurely something is changed
in the program.) The output of this program could be used by the
compiler for constness hints.

I'm not sure if the current way const is heading is for better (read, more
productive, i.e. safer and /faster/ ) programming, or if it is for better
compiler omtimizability in a multithread+multiprocessor setting,
forgetting the poor programmer.

I personally see the primary reason for const as the former and I think D2
is beginning to do that very well.
I think as far as compiler optimisation goes, any declarations that state
what can & can't happen to variables has the potential to be valuable. As
such, provided there is also an advantage to the programmer and as such is
not simply an inconvenience, declarations of this nature are desirable to
include.

Of course, the holy grail would be getting both, but I'm not so sure that
is even within reachability of D2. Maybe D3, though? In that case should
we try to get there one step at a time? But then, where should we draw the
line on how far we try to get with D2?

I see D2 as achieving more the safer programming aspect than the
multiprocessor optimisation. I suspect that much more is required to achieve
the latter but as I say, every little declaration helps =)