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.
