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.

"Georg Wrede" <georg@nospam.org> wrote in message news:47F04DD4.8020803@nospam.org...
> 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 =)