D const design rationale

[Walter Bright]

Sean Kelly wrote:
> However, my point was that to a programmer, 
> optimization should be invisible.

I can't agree with that. The compiler and the programmer need to 
cooperate with each other in order to produce fast programms. If a 
programmer just throws the completed program "over the wall" to the 
optimizer and expects good results, he'll be sadly disappointed.


> I can appreciate that 'invariant' may 
> be of tremendous use to the compiler, but I balk at the notion of adding 
> language features that seem largely intended as compiler "hints."

It's a lot more than that. First, there's the self-documenting aspect of 
it. Second, it opens the way for functional programming, which can be of 
huge importance.


> Rather, it would be preferable if the language were structured in such a 
> way as to make such hints unnecessary.

That would be preferable, but experience with such languages is that 
they are complete failures at producing fast code. Fast code comes from 
a language that enables the programmer to work with the optimizer to 
produce better code.

Lots of people think that just 'cuz they write in C++, which has good 
optimizers available, they'll get fast code. That's not even close to 
being true.


> To that end, and speaking as 
> someone who isn't primarily involved in numerics programming, my 
> impression of FORTRAN is that the language is syntactically suited to 
> numerics programming, while C++ is not.  Even if C++ performed on par 
> with FORTRAN for similar work (and Bjarne suggested last year that it 
> could), I would likely still choose FORTRAN over C++ because the syntax 
> seems so much more appealing for that kind of work.

I programmed for years in FORTRAN. The syntax is not appealing, in fact, 
it sucks. The reason it is suited for numerics programming is because 
FORTRAN arrays, by definition, cannot be aliased. This means that 
optimizers can go to town parallelizing array operations, which is a 
big, big deal for speed.

You can't do that with C/C++ because arrays can be aliased. I have a 
stack of papers 6" deep in the basement on trying to make C more 
suitable for numerics, and it's mostly about, you guessed it, fixing the 
alias problem. They failed.

There are some template libraries for C++ which parallelize array 
operations and can finally approach FORTRAN. But they are horrifically 
kludgy and complicated. No thanks. But the effort that has gone into 
them is astonishing, and is indicative of how severe the problem is.


>> I'm less sure about that. I think we're all so used to C++ and its 
>> mushy concept of const that we don't know yet what will emerge from 
>> the use of invariant. I do know, however, that those who want to do 
>> advanced array optimizations are going to want to be using invariant 
>> function parameters.
> 
> You may be right, and I'm certainly willing to give it a try.  This is 
> simply my initial reaction to the new design, and I wanted to voice it 
> before becoming placated by experience.  My gut feeling is that a better 
> design is possible, and I'm not yet ready to close the door on 
> alternatives.

Andrei, I and Bartosz have each expended probably a hundred hours trying 
to figure this out, and we've tried a lot of designs. If there is a 
better design, it's not like we haven't tried. I wish to reiterate that 
const designs in other languages like C++ (and to some extent Java) 
utterly fail at the objectives we set for const in D. Furthermore, 
Andrei is familiar with the many research papers on the topic, which 
were of invaluable help. D's const system is more ambitious than any of 
them.



> The compiler can inspect the code however, and a global const is as good 
> as an invariant for optimization (as far as I know).  As for the rest, I 
> think the majority of remaining cases aren't ones where 'invariant' 
> would apply anyway: dynamic buffers whose contents are guaranteed not to 
> change either in word or by design, etc.

But they do apply - that's the whole array optimization thing. You're 
not just going to have global arrays.