D const design rationale

[Sean Kelly]

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.  As for multithreading... I'll address that below.

>> Or am I missing something?
> 
> 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.  D may offer 'invariant' 
for this purpose, but practicality dictates that I would never apply 
'invariant' to 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.  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.

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.


Sean