D const design rationale

[Walter Bright]

Sean Kelly wrote:
> Walter Bright wrote:
>> Sean Kelly wrote:
>>> Matter of opinion, I suppose.  The C++ design was immediately clear 
>>> to me, though it obviously wasn't for others.  I grant that the 
>>> aliasing problem can be confusing, but I feel that it is a peripheral 
>>> issue.
>>
>> I don't think it is a peripheral issue. It completely screws up 
>> optimization, is useless for threading support, and has spawned 
>> endless angst about why C++ code is slower than Fortran code.
> 
> As a programmer, I consider the optimization problem to be a non-issue. 
>    Optimization is just magic that happens to make my program run 
> faster.

Optimization often makes the difference between a successful project and 
a failure. C++ has failed to supplant FORTRAN, because although in every 
respect but one C++ is better, that one - optimization of arrays - 
matters a whole lot. It drives people using C++ to use inline assembler. 
They spend a lot of time on the issue. Various proposals to fix it, like 
'noalias' and 'restrict', consume vast amounts of programmer time. And 
time is money.

Optimization issues often drive the choice of language. That really 
makes it an issue!


>> Yes, you've missed the distinction between a readonly view and a truly 
>> immutable value. That's not surprising, since my experience is that 
>> very few who are used to C++ const see the difference, and it took me 
>> a while to figure it out.
> 
> I didn't miss it, but I'm afraid I don't see how D fares much better 
> than C++ in this respect.  In a typical program, I see two basic 
> situations for manipulating external data: first, it may be a reference 
> parameter passed into a function call, or second, it may be a global 
> variable of some sort.
> 
> In the first case I assert that it is impossible to make any assumptions 
> about the inherent immutability of the data.

Right, hence the need for invariant.

> D may offer 'invariant' 
> for this purpose, but practicality dictates that I would never apply 
> 'invariant' to function parameters.

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.

> 'invariant' by itself is too 
> restrictive for general use, so overloads must be provided, and 
> maintaining 2-3 instances of the same routine with different parameter 
> qualifiers invites more trouble than it prevents.

For a function that wants to accept invariant and mutable parameters, 
declare them to be 'const'.

> C++ has no 
> equivalent, so there is no direct comparison there--mutability must 
> always be assumed.
> 
> In the second case, it is generally inherently obvious whether the data 
> is mutable.  Either it is a simple const-qualified global declaration, a 
> reference is returned from a global routine of some sort that has 
> documented guarantees about its mutability, etc.  These are the cases 
> most likely to eschew mutexes in a multi-threaded program.

The problems with documentation are legion. It's inevitably wrong, out 
of date, incomplete, or missing. Furthermore, the compiler cannot make 
any use of documented characteristics, nor can it check them.

> I will grant that 'invariant' may well be useful for writing 
> self-documenting code at the highest level of an application, but I 
> continue to wonder whether this offers a benefit sufficient to outweigh 
> the complexity it adds to the design.  This is the real crux of my 
> argument, and what I am hoping will come clear through discussion.  My 
> initial reaction to the const design for D was "what the heck is this? 
> well, I guess I'll figure it out when it's explained better," and though 
> I feel I am gaining a better understanding now, my initial reaction 
> greatly tempers my enthusiasm for the design.  In my opinion, if 
> something is not inherently obvious then it is probably 
> over-complicated, and I remain hopeful that a some simplification can be 
> found that does not sacrifice much of the expressiveness of the current 
> design.

I share your concern, there, but we tried about everything for months, 
and nothing else worked.