On Tuesday, 11 September 2012 at 17:57:17 UTC, David Piepgrass
wrote:
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.
Like i have written above, when switching from C++ to C# i found
it at first annoying but now i wished i would have it in C++ too.
One possibility to simulate this in C++ is like the pbrt people
have done it with const references and pointers (look at my post
above for further details).
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.)
+1
It's not only that you yourself want to 'scan' through your code
and QUICKLY see where parameters in function calls are modified
but others might have to read your code aswell for code reviewing
without browsing in the hopefully existing documentation for
every single function / method. People in companies normally are
not programming in isolation but are working in a team and teams
often change.
IMHO it is better left to the future D editor.
That's probably a long way off.
Yes. Looking at the current overall state of the d toolchain that
might be a very long way off.
And even then, inmho, it would be a not so good solution because
it would be a feature which would tie users who want this feature
to a specific editor / ide.
