Rvalue references - The resolution

[Jonathan M Davis]

On Thursday, May 09, 2013 21:30:00 Rainer Schuetze wrote:
> On 04.05.2013 20:33, Walter Bright wrote:
> > Static Compiler Detection (in @safe mode):
> > 
> > 1. Do not allow taking the address of a local variable, unless doing a
> > safe type 'paint' operation.
> 
> I'm not exactly sure what a "safe type paint operation" does, and
> whether the following has already been considered, but I just like to be
> assured it has:
> 
> Taking a slice of a stack allocated fixed-size array also includes
> taking its address, so it is also forbidden? This might disallow any
> range based algorithms on the static array.

Asuming that taking the slice of a static array is treated like ref (as @safe) 
rather than like taking the address of a local variable is (as @system), then 
we'll have to add similar runtime checks for arrays, and that would be way, 
way worse given that without purity, they could be assigned to a global 
dynamic array (or could be assigned to a member variable in a return value 
even with pure functions). It's fairly clean for ref simply because ref is a 
storage class and not a type constructor. Array slices on the other hand could 
escape all over the place.

I'm inclined to believe that taking a slice of a static array should be 
considered @system just like taking the address of a local variable is 
considered @system. If I could, I'd even disallow the implicit slicing of 
static arrays when passing them to functions taking dynamic arrays, but I 
question that Walter would go that far. But I don't know what we can do other 
than making slicing static arrays @system given how difficult it would be to 
have runtime checks catch that.

I'd brought this issue up in the past but had not remembered it during the 
recent discussions on ref safety. Good catch. We don't want any holes like 
this to persist.

- Jonathan M Davis