[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