@safe leak fix?

[grauzone]

Denis Koroskin wrote:
> I don't like his proposal at all. It introduces one more hidden 
> allocation. Why not just write
> 
> char[] buf = new char[100];
> 
> and disallow taking a slice of static array? (Andrei already hinted this 
> will be disallowed in @safe, if I understood him right).

I think that would be the best. What uses of static arrays are there?
- allocating memory "inline" (eh, you better not use SafeD if you need 
this! new always works)
- as value types, e.g. small vectors (don't really need slices in this case)
- ...?

> Speaking about safety, I don't know how we can allow pointers in safe D:
> 
> void foo()
> {
>    int* p = new int;
>    p[1000] = 0; // Will it crash or not? Is this a defined behavior, or 
> not?
>    // If not, this must be disallowed in safe D
> }
> 
> And, most importantly, *why* users would want to work with pointers in 
> safe D at all?

As far as I understood, pointers are supposed to be allowed in SafeD. 
You just aren't allowed to do the following things:
- pointer arithmetic
- turning arrays into slices
- taking address (messy one!)
- (unsafe) casts between pointers
- array.ptr
- probably more