ref arguments

[Steven Schveighoffer]

On Mon, 21 Sep 2009 12:23:46 -0400, Jeremie Pelletier <jeremiep at gmail.com>  
wrote:

> Steven Schveighoffer wrote:
>> On Mon, 21 Sep 2009 11:51:28 -0400, Jarrett Billingsley  
>> <jarrett.billingsley at gmail.com> wrote:
>>
>>> On Mon, Sep 21, 2009 at 11:43 AM, Steven Schveighoffer
>>> <schveiguy at yahoo.com> wrote:
>>>
>>>> in means that it's a reference that cannot be changed.  In D1, it  
>>>> means you
>>>> cannot change the value, but if the value contains a reference to  
>>>> something
>>>> else (like an array), you can change what it points to.
>>>
>>>> in: Use this for pass by reference for a value that you won't change
>>>
>>> No, sorry, this is wrong. In D1, 'in' is the default (pass by value)
>>> and does nothing.
>>  Oh, that's... um useless...  Pardon me for thinking it meant something  
>> ;)
>>  I'm pretty sure it means something in D2 though.
>>  -Steve
>
> 'in' means 'const scope' in D2, which is using pass-by-value semantics.

Yes, you are right.  I can't see the benefit to it, so I guess my  
recommendation is not to ever use in (use const instead).

> I myself stay out of 'ref' and 'out' params since they do not yet  
> optimize and add quite a lot of overhead making temporary "safe" copies  
> of the data.

I understand the problem behind not optimizing  (inline), but I'm not sure  
what you mean by making temporary "safe" copies.

> Also 'scope' params have a meaning, when a delegate parameter is  
> declared as scope, it allows a closure to use stack storage instead of  
> the usual heap storage.

yes, but in the context of an 'in' parameter, most of the time you are not  
passing a delegate using in, so scope doesn't mean much there.

-Steve