Ref parameter: intended behavior or bug?

[Bill Baxter]

Mike Parker wrote:
> Regan Heath wrote:
> 
>>
>> I think the concept of passing by reference is that when you pass by 
>> ref the parameter _is_ the original variable in every possible way.  
>> The compiler might be using a proxy object to implement this, it might 
>> not be, IANACW.  As such when you ask for the size of a ref parameter 
>> you're asking for the size of the original variable, which in this 
>> case is the size of the struct itself.
> 
> Yeah, I get it, but it still /feels/ inconsistent to me. If the size of 
> a class reference is 4 bytes, then it seems to me that the size of a ref
> parameter should be the same and not the size of the object to which it 
> refers. 

Consider the sizeof to mean how much space you would have to reserve if 
you were going to copy the thing into opaque memory somewhere.  If you 
try to copy a class reference then you need exactly 4 bytes.  (You 
cannot make a copy of the thing referred to.)  But if you tried to make 
a copy of a ref-passed struct{float x,y,z} then you would indeed need 12 
bytes because trying to copy the ref parameter will actually copy the 
thing referred to.  You can't make a copy of the reference itself.  At 
least not without dipping into pointer shenanigans.

> But I suppose we aren't supposed to think of a ref parameter as 
> a true reference, but rather as a mutable view of the original data. In 
> which case, 'inout' seems more appropriate, in retrospect, than 'ref'.

Except someday soon we'll probably have working 'const ref' parameters, 
and 'const inout' makes no sense.

--bb