Would like to see ref and out required for function calls

[David Piepgrass]

>>> void func (ref int[], int)
>>>
>>> If ref/out were required at the call site, this destroys UFCS.
>>>
>>> int[] array;
>>> array.func(0); // error, ref not specified by caller
>>
>> For UFCS, ref should be implied.
+1

> Why? UFCS means uniform function call syntax.
It is already understood that the thing left of '.' may be passed 
by reference:

struct Foo { int x = 0; void f() { x++; } }
void obvious()
{
    Foo foo; foo.f(); // x is passed to f() by reference
}

Perhaps your argument makes sense for classes, but not for 
structs. In any case the syntax (ref foo).f() would require extra 
work for Walter so I would not propose it. What I might propose 
instead is that, if the user requests (via command-line argument 
such as '-callSiteRef') that a warning be issued for arguments 
passed without 'ref' at the call site, then a situation like this 
should prompt a warning.

class Bar { int b; }
void changeBar(ref Bar b) { b = new Bar(); }
void warning()
{
     Bar bar = new Bar();
     bar.b = 10;
     bar.changeBar(); // Warning: 'bar' is implicitly passed by 
reference. To eliminate this warning, use 'changeBar(ref bar)' 
instead or do not compile with '-callSiteRef'
}

Again, this problem only applies to classes, since it is 
understood that structs are normally passed by reference.

>> Also for 'const ref' parameters, callsite ref should not be 
>> necessary.
>>
> The callee might escape a pointer to the argument. Which is
> 'non-obvious' as well when there is no callsite ref.

If you're referring to the fact that it's easy to have a D 
pointer to a stack variable outlive the variable... I don't think 
that this 'flaw' (I think of it as a flaw, others may think of it 
as a feature) is a good enough reason to say 'call site ref 
should be required for const ref parameters'.

>> for value types, it is arguably important.
>
> This is not necessarily a valid conclusion. Popularity does not 
> imply importance.

I think 'ref' is a popular idea because people have used it in C# 
and liked it. I didn't start putting 'IN OUT' and 'OUT' in my C++ 
code until C# taught me the value of documenting it at the call 
site.

>>> Generally speaking, if a parameter being
>>> ref/out is surprising, there is something wrong with the 
>>> design.  (There
>>> are times it is non-obvious in otherwise good code, this 
>>> seems uncommon.)

I often want to 'scan' code to see what it does. Especially for 
debugging, I want to see where the side-effects are QUICKLY. 
Guessing which parameters are 'ref' requires me to analyze the 
code in my head. Even if I myself wrote the code, it can be time 
consuming. That's why I would prefer to explicitly mark possible 
side effects with 'ref' (of course, when passing a class to a 
function, the class members may be modified when the reference to 
the class was passed by value. But it is far easier to keep track 
of which classes are mutable than to keep track of which 
parameters of which functions are 'ref', because functions far 
outnumber classes.)

> IMHO it is better left to the future D editor.

That's probably a long way off.