[Issue 12625] implicit slicing of RValue static array should be illegal
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Thu Apr 14 09:29:36 PDT 2016
https://issues.dlang.org/show_bug.cgi?id=12625
--- Comment #10 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
> What are the rules for temporaries that aren't further used in the expression? In this case, the result of foo isn't passed into another function, just a slice is.
In C++, the temporary has to be valid until the end of the statement (which is
by far the safest approach from what I can see), but I'm not sure that we've
actually spec-ed it out to that level of detail in D. So, temporaries might
disappear sooner (though I'm inclined to think that they shouldn't).
Regardless,
int[1] foo()
{
return [1];
}
void main()
{
int[] a = foo();
}
is essentially equivalent to
int[1] foo()
{
return [1];
}
void main()
{
int a* = &foo();
}
and that doesn't compile even with @system.
I'm 120% of the opinion that slicing a static array should _always_ be
considered @system, and I really don't see much reason to make it any more
legal to slice a temporary static array than it is to take its address. And
isn't that pretty much what separates an lvalue and an rvalue - that the lvalue
is guaranteed to have an address that can be assigned to, whereas an rvalue
isn't guaranteed to have an address? By slicing a temporary static array,
you're basically treating an rvalue like an lvalue, which is clearly bad.
--
More information about the Digitalmars-d-bugs
mailing list