memory safety checks and trust

[Steven Schveighoffer]

On 4/13/20 3:50 AM, Walter Bright wrote:
> On 4/11/2020 7:43 PM, Timon Gehr wrote:
>> Clearly there is a bug or bad design if the address of a`` escaping in 
>> `b ~= &a` and in `b = [&a]` are not treated the same.
> 
> They are treated the same with dip1000.
> 
>> But like Adam I don't see why there should be such a check in 
>> @system/@trusted code at all. (I understand that there is a 
>> workaround, but that should not be required.)
>>
>> Can we please settle on making @safe actually memory safe and 
>> @system/@trusted actually trust the programmer?
> 
> Consider:
> 
>    @system int* pumpkin(int i) { return &i);
> 
> Should that give an error or not?

Yes. This one directly exposes dangling references, and is easily caught 
by the compiler.

> 
> I.e. where does one draw the line?
> 

Where it's possible to write valid code that is memory safe even though 
it cannot be proven.

For instance:

void foo()
{
	int*[] b;
	int a;
	b ~= &a;
         // use b but don't expose it outside foo
}

There are no memory safety violations there.

This one is also memory safe:

int*[] b;
void foo()
{
    int a;
    b ~= &a;
    // use b, but don't allow it to be exposed in a way that can result 
in corruption.
    b = b[0 .. $-1];
}

The first case is highly useful, as one often needs scratch space to 
perform complex calculations or graph algorithms. I see no reason to 
disallow it.

The second case is more questionable, because it's very easy for someone 
to keep a copy of b at some point, and then you have lost track of who 
has access to a's memory. But it still is possible for it to be safe. 
@system is supposed to mean "I know what I'm doing".

-Steve