http://d.puremagic.com/issues/show_bug.cgi?id=6442

           Summary: Allow for passing values with the 'ref' keyword
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: wfunction@hotmail.com


--- Comment #0 from wfunction@hotmail.com 2011-08-06 04:50:10 PDT ---
It would be AWESOME if you could pass by-ref parameters using the ref keyword
(ditto with 'out'):


    void foo(ref int bar) { ... }
    int i = 0;
    foo(ref i);   // <------- here

and

    void foo(out int bar) { ... }
    int i = 0;
    foo(out i);   // <------- here


This should be an _optional_ feature, to avoid breaking code and to aide with generics (saying 'ref' should, however, REQUIRE that the parameter be passed by ref).

Why?

Documentation.

It documents the fact that you're passing something by reference, avoids bugs where the variable is changed to be passed by value and the caller's code no longer works, and making it optional allows everything to still work as before.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442


bearophile_hugs@eml.cc changed:

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


--- Comment #1 from bearophile_hugs@eml.cc 2011-08-06 05:44:47 PDT ---
C#4 acts almost like this (the usage of ref and out is not optional, unless for COM interoperability).

Generally I like features that improve the code reliability. But where is some kind of "proof" that (optional) ref/out at the calling point make the code less bug prone?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #2 from wfunction@hotmail.com 2011-08-06 08:55:09 PDT ---
"Proof"?

Idk, do you want me to find an example of something that actually broke because of this?

I don't know too many languages that allow this (like you said, C# 4.0 just allows this in COM) so asking "proof" is a little too much, IMHO... it's hard to find broken C# COM-interop code that got fixed _precisely_ because of this.

But I can certainly make an example for you, if you so desire...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #3 from bearophile_hugs@eml.cc 2011-08-06 11:05:05 PDT ---
(In reply to comment #2)
> "Proof"?
> 
> Idk, do you want me to find an example of something that actually broke because of this?
> 
> I don't know too many languages that allow this (like you said, C# 4.0 just allows this in COM) so asking "proof" is a little too much, IMHO... it's hard to find broken C# COM-interop code that got fixed _precisely_ because of this.
> 
> But I can certainly make an example for you, if you so desire...

In issue 5409 I have asked for another feature that helps to avoid bugs. This feature request is backed by a large number of similar bugs found in already written production code. This not a proof, but for me it's enough evidence to forbid the (!x & y) pattern.

I'd like something that justifies to add this feature to D, something beyond just "C# has it, kind of". I know that it's hard to find, but on the other hand you are asking something to programmers (it's optional, but it's not hard to see D shops with coding conventions that ask to always use the ref/out at the calling point), so the feature must give something back.

This feature improves code readability, but in D you also have "const ref" that semantically-wise for the caller is not that different from a pass by value.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #4 from kennytm@gmail.com 2011-08-06 14:46:43 PDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > "Proof"?
> > 
> > Idk, do you want me to find an example of something that actually broke because of this?
> > 
> > I don't know too many languages that allow this (like you said, C# 4.0 just allows this in COM) so asking "proof" is a little too much, IMHO... it's hard to find broken C# COM-interop code that got fixed _precisely_ because of this.
> > 
> > But I can certainly make an example for you, if you so desire...
> 
> In issue 5409 I have asked for another feature that helps to avoid bugs. This feature request is backed by a large number of similar bugs found in already written production code. This not a proof, but for me it's enough evidence to forbid the (!x & y) pattern.
> 
> I'd like something that justifies to add this feature to D, something beyond just "C# has it, kind of". I know that it's hard to find, but on the other hand you are asking something to programmers (it's optional, but it's not hard to see D shops with coding conventions that ask to always use the ref/out at the calling point), so the feature must give something back.
> 
> This feature improves code readability, but in D you also have "const ref" that semantically-wise for the caller is not that different from a pass by value.

(Nitpick: you can't pass an rvalue with const ref in D.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442


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

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


--- Comment #5 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-08-06 15:02:36 PDT ---
While I agree that it can sometimes be confusing whether a function takes a value by ref or by value, I think that it would clutter code to be using ref at the call site like that. It also gives a false sense of security, since if it's not required, you could easily have code which calls functions which take arguments by ref where some of the calls use ref at the call site and some don't, ultimately confusing anyone reading the code, since it would give the impression that those using ref at the call site passed by ref and those that didn't didn't, which wouldn't be true.

The only way that this would really make sense, IMHO, is if it were required. And that would cause problems for generic code and for functions which are overloaded on ref or const ref. It would also potentially cause issues with auto ref parameters.

So, while this in interesting idea, I think that it's ultimately a bad idea.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #6 from wfunction@hotmail.com 2011-08-06 15:41:18 PDT ---
> This feature improves code readability, but in D you also have "const ref" that
semantically-wise for the caller is not that different from a pass by value.

Const ref has nothing to do with this. It's almost always an optimization issue, not a semantic issue. Ref/out is not for optimization: it's for documentation of the code. Considering that D does not even require variables to be initialized, it's at least helpful to be able to say, "Yes, I **DO** expect this variable to get a value after this function returns" at the call site.


John: It's pretty interesting how you always like the status quo (or just hate
my ideas in general). You've pretty much opposed every /single/ idea I've
proposed, arguing that you don't see a point to it, it's not that useful,
etc... but honestly, does /every/ programmer have to see a point to /every/
feature in a language in order for that feature to be potentially useful?
Unless you can think of a /disadvantage/ here (other than the usual "clutter"
argument, which you can blindly apply to any feature in any language for which
you don't see a point), the fact that you would never use because you can't
think of an advantage doesn't really say anything in itself.
It should be obvious that I'm not arguing for D to be a clone of C#. But there
ARE good features in C#, mind you -- and documenting ref/out parameters is one
of them. It's easy to type (4 letters total, including the space) and it
IMMENSELY improves readability (especially since D doesn't even enforce
initialization). Sure, you might never use it... and neither do I use "final
switch". But does that mean it's a bad idea?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-08-06 15:56:17 PDT ---
At this point, changes to the core language are not going to be made without a very good reason, so expect ideas (be they yours or someone else's) to have to add something significant to the language, or they're not likely to be accepted. And that's the sort of thing that it's very difficult to convince Walter of (who is who you really need to convince). Changes to the core language are going to be rare at this point. Non-breaking changes (such as this one) are more likely to be accepted, but the language definition is supposed to be essentially stable at this point. Generally, the only changes which are going to be made are those which overcome a flaw or corner case in the language which needs to be resolved. So, feel free to propose new ideas, but they have a very high bar to pass before they're going to make it in. And unless you can convince Walter that a feature is worth adding, it's not going to be added no matter how much value other people see in it.

As for whether I personally see value in a particular feature, _of course_ I'm likely to be against a feature that I see no value in. Wouldn't _you_ usually be against a feature that you see no value in? Now, that doesn't mean that there is no value in the feature or that it definitively shouldn't be added just because I don't like it. It just means that I'm arguing against it.

And in this particular case, I don't think that what your proposing really adds much value. Instead, it clutters code and risks being highly confusing if it's used inconsistently. So, I don't think that the feature should be added. If you can get Walter to agree with you, then it'll probably be added. But unless have solid arguments which quite a few people agree with, you're probably not going to manage that. And even if you do, Walter is hard to convince.

So, go ahead and suggest this feature. It may get in. Personally, I'm against it, and I seriously question that Walter would be in favor of it. But good luck.

On a side note, any language changes like this will probably have to undergo a fair bit of discussion in the newsgroup before Walter will agree to add it unless it's clearly a major improvement. So, if you really want this feature, you should bring it up in the newsgroup.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #8 from wfunction@hotmail.com 2011-08-06 16:14:57 PDT ---
> At this point, changes to the core language are not going to be made without a
very good reason, so expect ideas (be they yours or someone else's) to have to add something significant to the language, or they're not likely to be accepted.

Right. That part makes 100% sense.

But that's nothing like the arguments you've used against my ideas.


The part that doesn't make any sense is the "I don't see a point in it" or the "it clutters the language" argument...


> As for whether I personally see value in a particular feature, _of course_ I'm
likely to be against a feature that I see no value in.

There's a difference between:
"I don't see a value in that feature"
versus
"I don't see why ANY group of people would value that feature"
If NEITHER of those apply, then yes, I argue against it. But if I can see why
someone might like a feature (as I'm sure you do, even if you don't like it
yourself), then I don't dismiss it simply because I don't like it.




> Wouldn't _you_ usually be against a feature that you see no value in?

Examples? Here you go:

- I don't see a value in "final switch". I don't care that it's there, either.
- I don't see a value in "with". I even think it clutters the code. And yet I
don't care that it's there, either, because I can see why people (e.g. VB
users) would like it.
- I ***ABSOLUTELY HATE*** being forced to use "!is null" instead of "!= null"
to compare reference types. It doesn't make any sense to me, and IMHO it should
be removed from the language tomorrow.
But I'm not arguing against it.
Why? Because: I can see why people from other languages (VB, Python, etc.)
would find it more useful, even though to me it's just plain stupid.

So no, I don't argue against something just because I don't like it. There has to be a clear reason why it sucks, rather than "it sucks because it's not technically necessary for the language to be Turing complete, and I don't find it handy".

Let me know if you need more examples.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6442



--- Comment #9 from bearophile_hugs@eml.cc 2011-08-06 17:03:11 PDT ---
> John: It's pretty interesting how you always like the status quo

It's the way he is, everyone has the rights to be himself or herself. And ad hominem attacks are out of place in Bugzilla.


> - I don't see a value in "final switch". I don't care that it's there, either.

If you switch on an emum, it gives you a nice error if later you add a new item to the enum. Contrary to your proposal, this is a known source of bugs in C/C++ code.

By the way, I (vaguely) like this proposal, this is why I am commenting here. But to add a feature like this, that has a (small but evident) costs, you must somehow justify it. I agree it's hard to find such "proof".

And I think Jonathan is right, making its usage optional is probably going to give troubles.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------