inout/out static array parameter

[Regan Heath]

On Wed, 22 Feb 2006 11:42:15 +0000 (UTC), Tom <Tom_member at pathlink.com>  
wrote:
> In article <ops5dcznaa23k2f5 at nrage.netwin.co.nz>, Regan Heath says...
>>
>> On Wed, 22 Feb 2006 16:09:47 +1100, Derek Parnell <derek at psych.ward>  
>> wrote:
>>> On Wed, 22 Feb 2006 17:16:30 +1300, Regan Heath wrote:
>>>
>>>> On Wed, 22 Feb 2006 14:15:32 +1100, Derek Parnell <derek at psych.ward>
>>>> wrote:
>>>>> On Wed, 22 Feb 2006 03:02:22 +0000 (UTC), Tom wrote:
>>>>>
>>>>>> Why is this illegal? Where does the documentation states this?
>>>>>> Does it have something to do with the matter that int[10] is  
>>>>>> allocated
>>>>>> onto the
>>>>>> stack? Sometimes I think D losses its abstraction capability when  
>>>>>> one
>>>>>> has to be
>>>>>> concerned about this kind of differences.
>>>>>>
>>>>>> 5# void f(inout int[10] x)
>>>>>> 6# {
>>>>>> 7# 	x[0..$] = 99;
>>>>>> 8# }
>>>>>>
>>>>>> test.d(5): cannot have out or inout parameter of type int[10]
>>>>>
>>>>> I cannot see why D should be upset with this. The implementation  
>>>>> would
>>>>> be
>>>>> just be passing the address of the int[10] array, just as it does for
>>>>> 'in' parameters.
>>>>
>>>> Not quite, when you pass something as 'in' you always get a copy of  
>>>> it,
>>>> this is true even for arrays.
>
> This isn't true:

Yes, it is. The key is realising what it is you're actually passing, in  
this case an array reference. You're not passing the data which is in the  
array, just the reference to it.

> void f(in int[10] x)
> {
> x[0] = 99;
> }
>
> int[10] i;
> f(i);
> printf("%d\n", i[0]); // prints '99'
>
> So you get a copy of the pointer to the first element. That's plain  
> useless for
> everyone. I dream 'in' could protect content of the array someday.

See my last reply. The thing you get a copy of is the array reference, not  
the data to which it refers. The array reference is a pointer which points  
to the location in memory where the array data is stored, this address is  
also the location of the first array element, much like:

char *p = strdup("this is a test");

the address to which p points is the location of the character 't' from  
the word 'this'. A fixed-length array is very similar to a plain old  
pointer, except it also has array bounds checking and a hard coded length  
available, plus useful array operations.

See the docs Derek posted in his last reply, 'in' does not promise to  
protect the data to which the array reference refers, only the array  
reference itself.

> This is far from abstract a programmer from what's really happening. If  
> I code
> something like:
>
> void f(in int[10] x);
>
> Common sense will tell me that the 10 positions of my array are well  
> protected
> and they shouldn't be touched by 'f' and in return this isn't the  
> behavior.

I think everyone (including Walter) wants us to be able to do this sort of  
thing. Whether it's a good idea isn't really in doubt, what is, is how it  
can be implemented.

> Walter with all respect, this sucks! When will we have real protection
> attributes?

I suspect we'll have them as soon as Walter devises a way to implement  
them to his satisfaction.

> So the 'in' keyword for static arrays are perfectly useless and  
> introduces nothing (while in the background it is really "protecting"  
> the pointer to the first element -that doesn't need any protection-).

The 'in' keyword behaves the same way for arrays, classes and any other  
reference type, it protects the reference itself, not the data to which  
the reference refers.

Regan