[dmd-beta] rvalue references

[Steve Schveighoffer]

I think this all holds water. Destroy!
>
>Andrei
>
>
First, let me just say, I really like this change.  This makes the most sense to me.  I always felt it was an artificial limitation, especially when 'this' is passed by ref but is always bindable to rvalues.

But let me play devil's advocate here, because I think this needs to be fully vetted.

--------------------------

Issue 1:

In TDPL, you say:

for context:
void bump(ref int x) {++x;}


"If a function expects a ref, it accepts only "real" data, not temporaries;  anything that's not an lvalue is rejected during compilation; for example:

    bump(5); // Error! Cannot bind an rvalue to a ref parameter

This prevents silly mistakes when people believe work is being done but in fact the call has no visible affect."

This is in section 5.2.1


Now, this obviously becomes valid code.  Are you OK with this?  It seemed like a major explanation as to why refs don't bind to rvalues.  I personally think it's just "coder beware".

-----------------------------

Issue 2:

Another reason I remember you stating as to why rvalues cannot bind to ref is that it's not the most efficient semantics.  So if rvalues bind to both non-ref and ref, can you have overloads between ref and non-ref for optimization purposes?


Note that this is *valid* code with 2.058 (and probably many previous compilers):

import std.stdio;

void foo(ref int x) { writeln("ref"); }
void foo(int x) { writeln("nonref"); }

void main()
{
    int x;
    foo(x);
    foo(5);
}

prints:
ref
nonref

Will this still compile under the new rules, or will it be ambiguous?

-----------------------------

Issue 3:

The point that you cannot take an address of a ref value is going to cause a *lot* of existing code to fail.  I don't really like this rule for code that isn't marked @safe (which should disallow taking addresses anyway).  It seems overly restrictive, and it will be viral in nature.  I know you mentioned this is the "long term plan", are the other parts of this severable from this?  Is the plan to implement this right now or later?  Can you explain why the existing requirements that you don't use pointers in @safe code isn't enough?


-Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120411/e760e443/attachment.html>