More keywords? Or fewer?

[Davidson Corry]

> Jesse Phillips wrote:
> 
> If I understand your request correctly...

Well, not "request". Not even "proposal", at this point. More like "topic 
for speculation".

> ... the reasons for const... is to
> allow the programmer to define the rules for his variables, not
> because the compiler can't see when a variable doesn't change.
> 
> The short, the compiler gets to enforce const and invariant on the
> programmer.
> 
> That is to say the compiler could take written code and identify what
> is invariant and const, but if someone else extends this those won't
> be marked in that way because they have changed it. How is the
> compiler going to say, "don't change that." If it has to guess from
> usage?

Yes, that is one of two (at least two) reasons for using const etc.: to state 
a "declared constness contract" against which the /inferred/ constness behavior 
of the program can be double-checked. If the two contracts conflict -- an 
object is declared non-writable, but the program tries to write it -- the 
language can, at compile or at run time, catch the conflict and inform the 
programmer. But to infer this at compile time requires that the compiler 
have access to /all/ the source code for the system, not just for one source 
file.

And that is the second way to use these keywords: as a substitute for inference. 
Let the programmer declare the "constness contract" explicitly, and don't 
do code analysis to infer it. That way, you don't have to have access to 
anything more than a single source file. But you lose the double-check aspect 
of the language construct.

You also make the programmer do more work, and you introduce the possibility 
that the programmer will make mistakes when doing that work. For instance, 
if the programmer declares constness one way in one module, and a subtly 
different way in another module, and links the two object files together, 
they may not work as expected and the linker can't tell us why. Unless, perhaps, 
the compiler embeds constness-contract metadata into each object file, and 
the linker contains routines to analyze metadata from all object files it 
links, coordinate them and report conflicts... 

Bear also in mind that I am suggesting the language do whole-system inference, 
not only for constness issues, but also for exception safety (infers "nothrow" 
or "throws_only ExceptionX, ExceptionY and ExceptionZ") and for multiprogramming 
rendezvous (infers "synchronized" etc.), just as the language now does for 
memory allocation (automatic garbage collection).

If the kind of whole-system inference I am suggesting is possible (and I 
don't know whether or not it is), then a programmer /wouldn't have to/ use 
keywords to declare explicit contracts for constness, exception safety, multiprogramming 
etc. The compiler would just figure out what was needed and optimize for it.

And if the language does provide such keywords, and the programmer chooses 
to use them, then the compiler could do its analysis and say, "Well, you've 
told me that the program is going to do /this/ and /this/ and /this/. And 
I can see from my analysis that, no, it ain't. Let's talk."

-- Dai