D const design rationale

[Sean Kelly]

Walter Bright wrote:
> 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!

You're right of course.  However, my point was that to a programmer, 
optimization should be invisible.  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." 
Rather, it would be preferable if the language were structured in such a 
way as to make such hints unnecessary.  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.

>>> 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.

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.

>> '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'.

Well sure.  But that merely supports my point that 'invariant' may be 
too specialized to justify the conceptual complexity it adds.

>> 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.

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.

>> 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.

Perhaps I'm just a few months worth of discussion behind then.  I'll 
admit that what I'm mostly doing here is poking the haystack to see if 
anyone tumbles out.


Sean