[Issue 12872] Feature request: Allow ref in arguments at the callsite

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12872

Jonathan M Davis <jmdavisProg at gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg at gmx.com

--- Comment #2 from Jonathan M Davis <jmdavisProg at gmx.com> ---
While I understand the motivation behind this, it really doesn't make sense.

1. It's essentially pointless unless it's required that ref be at the call
site, otherwise while ref at the call site then tells that that argument is
accepted by ref, it tells you _nothing_ about any argument that isn't marked
with ref - maybe it's being passed by ref, and maybe it isn't. So, you still
have to look at the documentation or function signature in order to determine
whether a function is accepting a particular argument by ref or not. So, ref
would need to be required at the call site for this to make sense. Making this
change would be a breaking change, and I very much doubt that Walter would go
for it at this point - particularly when at one point, he was considering
having ref accept rvalues once the safety checks for ref that were being
discussed at the time were put in place, and accepting rvalues is going in the
complete opposite direction of this enhancement request.

2. Even if we could made the changes, they would _not_ play nicely with UFCS.
There's nowhere to place the ref at the call site when the argument is being
used with UFCS.

If the concern is that we want it to be explicit when passing by reference or
pointer, and passing by pointer is undesirable because taking the address of a
local variable forces the caller to then be @system or @trusted, then I think
that we would be better served by doing something with scope that made it so
that if the pointer parameter were scope, and you took the address of a local
variable to pass to it directly, then it would be @safe, because the compiler
could guarantee that the pointer wasn't escaping.

--