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