D const design rationale

[Walter Bright]

Sean Kelly wrote:
> Walter Bright wrote:
>> 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 suppose the issue is where the line should be drawn, and that line is 
> constantly shifting.  Previously, "register" was actually a valuable 
> tool in C/C++, now it's a pointless anachronism.  Techniques for 
> producing optimal loops varied across compiler and platform--in some 
> cases using pointers was better, in some cases array indexing was 
> better--and now those are largely pointless as well.  But I think there 
> are a few different factors to be considered here.  A significant one is 
> that compilers have simply gotten better.  Another is that hardware has 
> improved tremendously.  But it's interesting that you mentioned FORTRAN 
> as being the language to beat for numerics performance because it's 
> positively ancient and, to my knowledge, does not require the programmer 
> to make any extra effort to produce such optimal code.  It's just a 
> side-effect of the language design.

It's a side effect of:

1) no pointers
2) no aliasing

It's not a result of genius on the part of FORTRAN's designers. And it's 
only more efficient for certain types of code - for everything else, it 
sucks.


> I'm sure you recognize this because D has 'foreach', which is as much an 
> optimization tool as it is a programming aid.  The thing is, 'foreach' 
> would be great from a programmer perspective even if it were the bane of 
> compiler optimization.  It clarifies loop syntax, reduces errors, and 
> adds a great deal of flexibility for iteration.  These are sort of 
> features I want to see in D: those that make code more elegant and 
> maintainable, and which produce optimal code simply as a side-effect of 
> their design.  I suppose this is one reason I'm not quite ready to give 
> up on "const by default" yet.  Converting code may be more difficult 
> than with the current design, but the result seems to have the potential 
> to be both cleaner and more suited to deep compiler optimization.
> 
>>> 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.
> 
> Could you explain?  I've been trying to determine how I would write a 
> library using these new features, and so far, 'invariant' simply seems 
> more an obstacle to maintainability (because of the necessary code 
> duplication), than it is an aid to programming.

For one thing, if you have a reference to an invariant in a 
multithreaded program, you won't have to worry about putting a lock 
around it in order to read it.

For the FP aspect, it means that if a function only depends on its 
parameters, and its parameters are passed by value, the compiler has 
enough information about it to reorder when the function is executed, 
which means it can parallelize it.

If the compiler cannot determine the side effects, it is forced to 
execute the functions serially.

>> 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.
> 
> Really?  I thought that many functional programming languages were quite 
> fast.

I didn't mean FP languages, I meant languages where one is supposed to 
ignore optimization and let the compiler do it all.

> And FORTRAN seems a suitable example for an imperative language 
> which is quite fast as well.  To my knowledge, none of these contain 
> features specifically intended for optimizing code.

It's an unintended side effect of FORTRAN's primitive semantics.


>> 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.
> 
> That's the big secret?  Weird.  For some reason I assumed it was a bit 
> less specific.

That's the big secret.


> I really do appreciate the effort which you all have made to find a 
> solid design, and perhaps I simply don't have enough experience with it 
> to feel comfortable with it yet.  As you've no doubt noticed, my issue 
> is with 'invariant' from a conceptual and a code maintenance standpoint. 
>  On the one hand we have 'const' and on the other we have 'really really 
> const'.  It just sticks in my craw that we need two separate keywords 
> for what seem to be nearly identical properties, and that I may have to 
> write separate code to suit each, etc, not to mention trying to explain 
> all of it to a new programmer.

It's like int and uint - most of the time, they behave the same. But 
when they're different, they're very different.


> Perhaps I misunderstood the "must be known at compile-time" clause.

That's only when you use invariant as a storage class. It doesn't apply 
when you use it as a type constructor.

>  Can 
> 'invariant' apply to dynamic arrays that will remain unchanged once 
> initialized?

Yes.

   In my work I use almost no static data--it's all generated
> on the fly or loaded from some data source.  Will 'invariant' help to 
> make my code more optimal?

Not with the current compiler, because the back end hasn't been modified 
to take advantage of it. But the potential is there.