Thread overview
[Issue 12872] Feature request: Allow ref in arguments at the callsite
Jun 07, 2014
Jonathan M Davis
Jun 07, 2014
Brad Anderson
Jun 16, 2021
Mathias LANG
Jun 16, 2021
apham
Jun 16, 2021
apham
June 06, 2014
https://issues.dlang.org/show_bug.cgi?id=12872

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #1 from bearophile_hugs@eml.cc ---
People keep asking for this feature from the C# language, and it keeps being shot down. This is becoming the most commonly refused enhancement request for D.

--
June 07, 2014
https://issues.dlang.org/show_bug.cgi?id=12872

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

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

--- Comment #2 from Jonathan M Davis <jmdavisProg@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.

--
June 07, 2014
https://issues.dlang.org/show_bug.cgi?id=12872

--- Comment #3 from Brad Anderson <eco@gnuk.net> ---
> 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. ...

I agree that without enforcement this enhancement request is less useful than it could be but it is still beneficial for at least two things:

- Self documenting the code. Even if just optional it'd be nice to see at a
glance that a reference is being taken. Sure, you could add /* passed by ref */
in there but it's noisier than it needs to be.
- Error when the callsite ref disagrees with the function. If you've called
with ref but the function doesn't accept ref then you've made an obvious error
and should be told about it. This is very similar to the override keyword which
is genuinely useful and catches real bugs. This wouldn't be a breaking change
so it'd be safe to enforce.

> 2. Even if we could made the changes, they would _not_ play nicely with UFCS.

Yeah, and that's the first thing I thought of that would be a problem with enforcing it and one of the reasons I'm not requesting enforcement with this enhancement request, only mentioning that it could be done in the future potentially.

> ...doing something with scope...

I'd love for this to happen (I wish reference types were scope by default personally). I don't think scope pointers should just replace `out` though.

Side rant: If we had warning levels like every other compiler in existence than we could have people opt into an enforcement warning for this but I don't think Walter will budge on that. :(

--
June 16, 2021
https://issues.dlang.org/show_bug.cgi?id=12872

Mathias LANG <pro.mathias.lang@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |pro.mathias.lang@gmail.com
         Resolution|---                         |WONTFIX

--- Comment #4 from Mathias LANG <pro.mathias.lang@gmail.com> ---
I also would like to see this, however, as it stands, this would have to go through the DIP process to make it into the language. Closing as it's not a bug and is not actionable.

--
June 16, 2021
https://issues.dlang.org/show_bug.cgi?id=12872

apham <apz28@hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |apz28@hotmail.com

--- Comment #5 from apham <apz28@hotmail.com> ---
Actual benefit is for variadic arguments function call. For this case, it allows callside to specify how argument to be passed. This also allow to create generic template to define delegate/event

void print(A...)(A a)

or

struct DelegateList(Args...)
{
    alias DelegateHandler = void delegate(Args args);

    DelegateHandler[] items;

    void opCall(Args args)
    {
        foreach (i; items)
            i(args);
    }
}

--
June 16, 2021
https://issues.dlang.org/show_bug.cgi?id=12872

--- Comment #6 from apham <apz28@hotmail.com> ---
Actual benefit is for variadic arguments function call. For this case, it allows callside to specify how argument to be passed. This also allow to create generic template to define delegate/event

void print(A...)(A a)

or

struct DelegateList(Args...)
{
    alias DelegateHandler = void delegate(Args args);

    DelegateHandler[] items;

    void opCall(Args args)
    {
        foreach (i; items)
            i(args);
    }
}

--