DIP1000: Memory Safety in a Modern System Programming Language Pt.1

[Steven Schveighoffer]

On 6/22/22 5:44 PM, Dukc wrote:
> On Wednesday, 22 June 2022 at 21:07:50 UTC, Ola Fosheim Grøstad wrote:
>> On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven Schveighoffer wrote:
>>> The part about `scope` being shallow. This is a problem.
>>
>> One thing that will be confusing to most users is that it appears to 
>> be using "taint" rather than proper flow analysis on the 
>> pointed-to-object?
>>
>> ```d
>> int* test(int arg1, int arg2) {
>>     int* p = null;
>>     p = &arg1;
>>     p = new int(5);
>>     return p;  // complains about p being scope
>> }
>> ```
> 
> I'd personally prefer if variable `scope` auto-inference worked only in 
> the declaration, not later assignments. I guess the intention is to 
> break less existing code.

I think this is the better option. Either that, or that when it returns 
`p` that trumps any possible `scope` inference.

Imagine you have a function like this:

```d
int foo()
{
    int x = 0;
    x = long.max;
    x = 2;
    return x;
}
```

Now today, this causes an error on the assignment to `long.max`, because 
obviously `x` is an int. But what if, instead, the compiler decides to 
backtrack and say "actually, if I make x a `long`, then it works!", and 
*now*, at the end, says "Oh, actually, you can't return a long as an 
int, what were you thinking?!"

This is the equivalent here, you declare something *without* scope, 
assign it to something that is *not* scope, and then because sometime 
later you assigned it to something that *is* scope, it goes back and 
rewrites the declaration as if you did make it scope, and then complains 
to you that the magic trick it tried is not valid.

This is going to be one of the most confusing features of DIP1000.

-Steve