Passing dynamic arrays

[Daniel Gibson]

Jonathan M Davis schrieb:
> On Monday, November 08, 2010 10:35:38 Daniel Gibson wrote:
>> bearophile schrieb:
>>> Jens Mueller:
>>>> I find this behavior rather strange.
>>> I don't know if it's strange, but surely it is a little bug-prone corner
>>> of D. I have had two or three bugs in my code because of that.
>> If you pass a dynamic array to a function and chance it's size within the
>> function, you have undefined behaviour - you never know if it will affect
>> the original array (from the calling function) or not.
> 
> Implementation-defined behavior would be more accurate. Undefined would mean that 
> it's something dangerous which is not defined by the language, and you shouldn't 
> be doing. It's perfectly defined by the language in this case. It's just that how 
> much extra memory is allocated for a dynamic array is implementation-defined, so 
> in cases where a reallocation would be necessary because the array ran out of 
> memory, it's implementation-dependent as to whether or not a reallocation will 
> be necessary or not. In every other case, it's completely language-defined and 
> deterministic. The algorithm for additional capacity is the only part that 
> isn't.
> 

Ok, undefined may have been the wrong word.. non-deterministic may be better.
Anyway, you can't know if there's space left behind the array that can be 
obtained by realloc or if increasing the length will cause the array to be 
copied to a new block of memory, so the array in the calling function points to 
other memory than the array in the called function.



>> So IMHO a compiler warning would  be appropriate in that case.
>>
>> (It would be even better to have more consistent array handling throughout
>> the different kinds of arrays, as I wrote in another branch of this
>> thread, but if that is no option, for example because it contradicts TDPL,
>> a compiler warning is a good compromise)
> 
> Honestly, if you want an array that you're passing in to be altered by the 
> function that you're passing it to, it really should be passed by ref anyway. 

The documentation[1] says: "For dynamic array and object parameters, which are 
passed by reference, in/out/ref apply only to the reference and not the contents."
So, by reading the documentation one would assume that dynamic arrays are passed 
by reference - *real* reference, implying that any change to the array within 
the called function will be visible outside of the function.
The truth however is that dynamic arrays are not passed by reference and any 
changes to the length will be lost (even if the arrays data won't be copied).

> And if you want to guarantee that it isn't going to be altered, make it const, 
> dup it, or have its individual elements be const or immutable. Problem solved. I 
> really don't see this as an issue. I can understand why there might be some 
> confusion - particularly since the online docs aren't very clear on the matter, 
> but it really isn't complicated, and I'd hate to have to dup an array just to be 
> able to append to it, which is what the warning that you're suggesting would 
> require. A compiler warning is as good as an error really, since you're going to 
> have to fix it anyway, so I'd definitely be against making this either an error or 
> a warning. I see no problem with being allowed to resize arrays that are passed 
> to functions.

So maybe yet another solution would be to *really* pass dynamic arrays by 
reference (like the doc pretends it's already done)?

> 
> - Jonathan M Davis

Cheers,
- Daniel

[1] http://www.digitalmars.com/d/2.0/function.html