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

[Ola Fosheim Grøstad]

On Thursday, 23 June 2022 at 00:45:09 UTC, Steven Schveighoffer 
wrote:
> 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.

It is confusing because it introduces flow typing without having 
flow typing. So this is messing up the user’s mental model of the 
type system, this is a basic usability flaw.

Track the object instead and don’t change the type of the pointer 
to scope.

If D wants to do flow typing, do it properly and make it clear to 
the user. It would be a good feature to have, but it would become 
D3.