Encapsulating trust

monarch_dodra via Digitalmars-d digitalmars-d at puremagic.com
Mon Sep 1 01:54:14 PDT 2014


On Monday, 1 September 2014 at 07:13:47 UTC, Dmitry Olshansky 
wrote:
>
> auto ref return FTW

I thought you had avoided that on purpose, in the sense that 
generic auto-ref input *and* output has been proven unsafe, in 
the sense that there are tons of ways for the compiler to 
accidently return a ref to something that is actually local.

unaryFun!"a[0]" or unaryFun"a.field" is a perfect example of that.
Or, say:
int tube(int a){return a;}
ref int tube(ref int a){return a;}
call!tube(5); //Here

>> - fails perfect forwarding of lvalues into rvalues.
>
> ?
>
> void inc(ref int a)
> {
>     a += 1;
> }
>     int b;
>     call!inc(b);
>     assert(b == 1);
>
> Works fine.

Yes, but:
call!inc(5) will *also* succeed.

But background on this issue would be certain functions, such as 
"emplace" that could elide postblit entirely when asked to 
emplace from an rvalue. The issue is that such functions that use 
auto-ref have a tendency to lose that information.

We could use "std.algorithm.forward", but that function is 
currently too expensive.

That said, there are no real functions that would exploit this 
"perfect forwarding" anyways. I filed:
https://issues.dlang.org/show_bug.cgi?id=12683
https://issues.dlang.org/show_bug.cgi?id=12684
After Andrei filed:
https://issues.dlang.org/show_bug.cgi?id=12628

Which would be the first steps to really start making more 
efficient use of rvalues in D.


More information about the Digitalmars-d mailing list