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
_______________________________________________
dmd-beta mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-beta
