Call site 'ref'

[Timon Gehr]

On 01/15/2012 02:36 PM, Alex Rønne Petersen wrote:
> Hi,
>
> I don't know how many times I've made the mistake of passing a local
> variable to a function which takes a 'ref' parameter. Suddenly, local
> variables/fields are just mutating out of nowhere, because it's not at
> all obvious that a function you're calling is taking a 'ref' parameter.
> This is particularly true for std.utf.decode().
>

Odd. I always thought the fact that std.utf.decode modifies the second 
parameter is very intuitive. (decoding cannot work nicely without it)

> Yes, I realize I could look at the function declaration. Yes, I could
> read the docs too. But that doesn't prevent me from forgetting that a
> function takes a 'ref' parameter, and then doing the mistake again. The
> damage is done, and the time is wasted.
>

This is true for every part of a function interface. How can a 
programmer even understand what the function does if he forgets what the 
calling conventions are? Conversely, does a reminder of the calling 
conventions usually restore full knowledge of the semantics of the 
called function?

> I think D should allow 'ref' on call sites to prevent these mistakes.
> For example:
>
> string str = ...;
> size_t pos;
> auto chr = std.utf.decode(str, ref pos);
>
> Now it's much more obvious that the parameter is passed by reference and
> is going to be mutated.
>
> Ideally, this would not be optional, but rather *required*, but I
> realize that such a change would break a *lot* of code, so that's
> probably not a good idea.
>
> Thoughts?
>

I personally think 'ref' at call site is pure syntax noise but I see 
that it might be useful to some in some cases. I'd prefer to leave it 
as-is, but I don't feel very strongly for either way.
My preference would be
[not allowed > enforced > ... > optional > optional with switch]

However, it is very important not to do this to 'lazy'.

Another thing that would have to be discussed: what happens to const ref 
parameters? It is very reasonable that someone will decide to change 
calling conventions from by value to by const ref or the other way round 
after profiling. It is very convenient that such a change is 
syntactically transparent to the caller and this should stay.

It is even realistic that someone will decide to interchange by ref/by 
value, because there is no way to express 'I will not change the head 
level' in the current type system other than taking a parameter by 
value. Therefore introducing call-site ref would perhaps necessitate 
re-introducing 'final' for variables.