On Thu, 09 May 2013 22:10:22 -0400, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
On Thursday, May 09, 2013 21:56:53 Steven Schveighoffer wrote:
What about specifying ref at the call site when you know you want the
data
modified?
fix(ref c[i]);
Then if c decides to start returning by value, this is a compiler error.
IMO, fix really should take a pointer. But we want to avoid pointers due
to the danger of them.
so this is like applying & but keeps it safe.
That would be great except for UFCS. How would you designate the ref
when it's
the first argument? And I think that it's worse to have ref optional at
the
callsite than to not have it at all.
1. using UFCS is optional. c[i].fix() works as well as fix(c[i]).
2. We could say UFCS has an implicit ref-at-callsite if needed, and will
not compile for rvalues. If you think about it, 'this' is implicitly ref,
and UFCS is calling like the first argument is the 'this' reference.
If it weren't for UFCS, I probably would be in favor of requiring it at
the
callsite, but I just don't see how that could work with UFCS. Maybe C#
has a
way to deal with that, since it does have some sort of UFCS, and it does
require ref at the callsite (at least from what I understand - I haven't
used
C# much)?
C# required ref when I used it. It was actually kind of nice because it
was self-documenting.
But I don't think it's something we could add as a requirement, too much
code uses ref.
I don't think it is bad to make it optional. The caller can put
restrictions he desires on types just like the callee can. Consider that
the author of fix could change his code to double fix(double), and now the
code also is useless. We can't possibly guard against that, because
lvalues also bind to non-ref.
I tend to feel that any modification that adds or removes ref is a severe
breaking change, and is so bad that it shouldn't be done without also
changing the name of the function anyway.
-Steve
