More on purity

[Timon Gehr]

On 12/21/2011 08:53 PM, bearophile wrote:
> This was discussed a little in D.learn. Is code like this going to compile in some future DMD versions, like DMD 2.058? I hit situations like this often in my code:
>
>
>
> int[] foo1(immutable int[] a) pure {
>      return new int[a.length];
> }
>
> int[] foo2(in int[] a) pure {
>      return new int[a.length];
> }
>
> void main() {
>      immutable int[] arr1 = [1, 2, 3];
>      immutable int[] r1 = foo1(arr1); // OK
>
>      const int[] arr2 = [1, 2, 3];
>      immutable int[] r2 = foo2(arr2); // error
> }
>
>
> Currently it gives:
> Error: cannot implicitly convert expression (foo2(arr2)) of type int[] to immutable(int[])
>
>
> If code like that can't be accepted in future D/DMD versions, then I think DMD should give an error message that explains why the r2 implicitly conversion is not acceptable (while the implicitly conversion to r1  is acceptable).
>
> Bye,
> bearophile


This particular case should work, because there is no possibility 
parameters and return value alias. Have you already filed an enhancement 
request about this? However, as soon as it looks like this:

Object[] foo3(const Object[] a) pure {
     // ...
}

Then it cannot compile when passed a mutable or const array anymore, whereas

Object[] foo3(in Object[] a) pure {
     // ...
}

Should work even then (but preferably after DMD starts to actually 
enforce 'scope').


I think the best solution to that more general problem would be to allow 
'inout' on the return value when it is not on a parameter.


Another thing: This should always work:
// T[] foo2(const T[]){...}; immutable T[] arr1
immutable T[] r3 = foo2(arr1); // currently error