D const design rationale

[Kristian Kilpi]

On Sun, 24 Jun 2007 07:44:33 +0300, Bill Baxter  
<dnewsgroup at billbaxter.com> wrote:
> Don Clugston wrote:
>> Walter Bright wrote:
>
>>> 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.
>>  How much of this will actually be solved by invariant?
>> It seems to me that typically, arrays are built up element-by-element,  
>> even if they never change again. I guess in D2.0, such code would  
>> initialize a temporary array, and finally idup it?
>>  The aliasing problem will be far from gone, though. Consider an  
>> in-place operation on a matrix. Frequently you modify one only row at a  
>> time, based on the remaining rows. I think you'd have to  
>> cast(invariant) those other rows, to avoid aliasing.
>
> Thanks for asking this.  It's been eating at me too.  From what I  
> understand of Fortran code, you declare an array of a given size, set  
> its values however you like, then pass it to a function.  But if we make  
> an invariant D array we can't set its values after initialization.  So  
> it doesn't seem very useful.  Or is the use pattern going to be, as you  
> say, Don, casting to invariant every time you need to call  
> fast_math_array_function()?  If that's the case I suspect it won't take  
> long before this becomes an idiom:
>
>     /* x += y array-style */
>     add_accum(double[] x, const double[] y) {
>        _add_accum_impl(cast(invariant)x,cast(invariant)y);
>     }
>
> Is that really what we want?
> That code can't even be right though, because x is *supposed* to get  
> modified there. So how do you denote lack of aliasing on something like  
> that using invariant?  In this respect C99's 'restrict' seems to be a  
> lot more understandable.  My naive understanding of it being that you  
> just slap it on any argument that you want to tell the compiler it can  
> assume to be non-aliased.
>
> --bb

I've been asking the same questions myself too.

In serial coding, will 'invariant' only be used (in practice) to solve the  
aliasing problem?
You have a mutable data structure, and you're passing it as an invariant  
to functions.
Lots of 'cast(invariant)' will occur.

In parallel coding, 'invariant' will be more useful. However, truly  
'invariant' data cannot ever
be changed. What I would want is a way to tell the compiler that the data  
will not be changed
*during the execution* of a function.


Hm, let there be the following function:

   void foo(invariant Bar bar);

Then I could use mutexes and casting as follows:

   MUTEX_LOCK(a)
   foo(cast(invariant)a);
   MUTEX_UNLOCK(a)

So 'cast(invariant)' will occur again.
The *programmer* needs to be sure that data passed to functions is truly  
invariant.


What if we drop out the 'invariant' keyword, and simply define that  
aliasing
is illegal (by default) and result in undefined behaviour?
That is, 'const' would mean a read-only view to immutable data (that  
cannot be changed
during the execution of a function).