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